RE: Stream device does not recognize a custom record type

["Abdalla Ahmad" <abdalla.ahmad@sesame.org.jo>]

Thank you Dirk. It worked fine.

I still have one more question. Another IOC has a similar ancient setup, configured to build with this record but not using it, so I removed the record references in the RELEASE and Makefile and the IOC complained about not finding the record dbd. I went back to the synApps 5.6 stream and built it without the record's support, now the IOC works fine. Does this make sense?

Best Regards,
Abdalla.

-----Original Message-----
From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch] 
Sent: Tuesday, October 02, 2018 10:26 AM
To: Abdalla Ahmad <abdalla.ahmad@sesame.org.jo>; tech-talk@aps.anl.gov
Subject: Re: Stream device does not recognize a custom record type



On 02.10.2018 08:42, Abdalla  Ahmad wrote:
> Hi Dirk
> 
> Thank you very much that was really helpful. The record gets compiled successfully and the IOC is running, but with one more problem. The IOC shell gives me this error:
> 
> Format "%x" has data type unsigned which does not match the type of "BO-RF-SGN1:getStatusWord"
> 
> In the protocol file we have:
> getStatusWord {
> 	out "STAT";
> 	in "%x";
> }
> 
> Now I tried searching the source code for something useful but did not get any. I changed the protocol from %x to %u did not work. Changed it again to %i and it seems working so far. Is there any additional configurations to be done or the record's source needs to be modified in order to parse such input formats?

Some time ago I started to handle signed and unsigned integers separately. That allows to handle sign extension properly. For mbbi the sign is not an issue. So simply check for DBF_LONG or DBF_ULONG in your devmssi2Stream.c simply check for DBF_LONG or DBF_ULONG and it will work.

     if (format->type == DBF_LONG || format->type == DBF_ULONG)


> 
> Best Regards,
> Abdalla.
> 
> -----Original Message-----
> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch]
> Sent: Monday, October 01, 2018 3:13 PM
> To: Abdalla Ahmad <abdalla.ahmad@sesame.org.jo>; tech-talk@aps.anl.gov
> Subject: Re: Stream device does not recognize a custom record type
> 
> On 01.10.2018 12:26, Abdalla  Ahmad wrote:
>> No idea unfortunately.
>>
>> Which make file do you mean? I used the following attempts in 
>> StreamDevice/streamApp/Makefile
> 
> The Makefile of the library that defines your record. In your mbbi2 folder.
> 
> I have attached my version of mbbi2.tgz with fixes that make it work for me with different EPICS base versions, producing different mbbi2Record.h files.
> 
> 1. No mbbi2Record.h in source code.
> 2. No mbbi2.dbd in source code. Split exising mbbi2.dbd into mbbi2Record.dbd and devmbbi2Soft.dbd.
> 3. Fix Makefile to generate mbbi2Record.h and mbbi2.dbd
> 
> # Generate mbbi2Record.h from mbbi2Record.dbd
> DBDINC		= 	mbbi2Record
> 
> # Generate mbbi2.dbd from mbbi2Record.dbd and devmbbi2Soft.dbd
> mbbi2_DBD	+=	mbbi2Record.dbd
> mbbi2_DBD	+=	devmbbi2Soft.dbd
> 
> # Install both, mbbi2.dbd and mbbi2Record.dbd
> DBD		+=	mbbi2.dbd
> DBD		+=	mbbi2Record.dbd
> 
> 
> For the DBDINC rule it is important that the dbd file has the same stem name as the to be generated header file, here "mbbi2Record".
> Thus make a mbbi2Record.dbd file. Basically split it off mbbi2.dbd.
> The library dbd file mbbi2.dbd becomes itself a generated file, made from the record mbbi2Record.dbd and its soft device support devmbbi2Soft.dbd.
> 
> Dirk
> 
> 
> 
> 
> 
> 
>>
>> DBDINC += mbbi2Record
>> DBDINC += mbbi2
>> DBDINC += mbbi2Record.h
>>
>> And every time I get
>>
>> dbdExpand.pl: No input files
>>
>> And the make exits with error.
>>
>> -----Original Message-----
>> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch]
>> Sent: Monday, October 01, 2018 1:11 PM
>> To: Abdalla Ahmad <abdalla.ahmad@sesame.org.jo>; 
>> tech-talk@aps.anl.gov
>> Subject: Re: Stream device does not recognize a custom record type
>>
>> How have you originally made the header file? Manually?
>>
>> Normally you don't have the xxxRecord.h file of your records anywhere in your source code. You only have the xxxRecord.dbd file.
>>
>> In the Makefile you have something like this:
>>
>> DBDINC += xxxRecord
>>
>> which will create O.Common/xxxRecord.h from xxxRecord.dbd using the 
>> current EPICS base version. It will be installed as 
>> $(INSTALL_LOCATION)/include/xxxRecord.h
>>
>> Do not store the created header file with your source code. Not in your code repo, not in your tar files. Rebuild it every time you build your library.
>>
>> Other drivers (e.g. StreamDevice) can find the installed xxxRecord.h and xxxRecord.dbd files if you include the install location of your record library in the RELEASE file of the other drivers. Do not copy the header file or the dbd file over to the other driver.
>>
>>
>> On 01.10.2018 11:07, Abdalla  Ahmad wrote:
>>> Hello Dirk
>>>
>>> Thank you for your suggestions.
>>>
>>> I do have some questions. Can you please explain more on how do I re-build the header file? You mean re-compile it with the new base version? Because the file is already in the source code I did not notice if it is automatically generated.
>>>
>>> I am already looking in the standard mbbiDirectRecord.h and see how it is implemented if that's what you mean.
>>>
>>> Best Regards,
>>> Abdalla.
>>>
>>> -----Original Message-----
>>> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch]
>>> Sent: Monday, October 01, 2018 11:59 AM
>>> To: Abdalla Ahmad <abdalla.ahmad@sesame.org.jo>; 
>>> tech-talk@aps.anl.gov
>>> Subject: Re: Stream device does not recognize a custom record type
>>>
>>> Hi Abdalla,
>>>
>>> I think I found your problem. You cannot use the mbbi2Record.h file generated with EPICS 3.14.12. You need to re-build it with the new EPICS base version. The reason is that this file is generated from your mbbi2.dbd file which includes dbCommon.dbd which may change from one EPICS version to another. That makes all the offsets of the fields wrong and accessing them using db functions like dbLoadLink results in wrong data being used. NULL pointer in your case.
>>>
>>> Dirk
>>>
>>> On 01.10.2018 09:44, Abdalla  Ahmad wrote:
>>>> Hello Dirk,
>>>>
>>>> I think somehow stream device is involved, not that the problem is in it but how it interacts with this new record type. In the example PV I showed I changed the record type from mbbi2 to mbbiDirect and it works fine.
>>>>
>>>> Regarding the stack trace there is something interesting. I looked up the mbbiDirect record source in base 3.15.5, specifically the file src/std/rec/mbbiDirectRecord.c and in the init_record routine (line 97), it first checks for a null device support entry table (struct mbbidset) before calling the function "recGblInitConstantLink". In the mbbi2 record this is inverted, it calls this function then checks for null pointer DSET. I re-arranged these two section to be the same as in the mbbi2Direct record and I got this on the IOC shell:
>>>>
>>>> Missing device support entry table PV: BO-RF-SGN1:getStatusWord mbbi2:
>>>> init_record
>>>>
>>>> dbGetLinkValue: Illegal link type 1 Thread _main_ (0x8eb40e0) can't 
>>>> proceed, suspending.
>>>> Dumping a stack trace of thread '_main_':
>>>> [0x260bc4]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(epic
>>>> s
>>>> B
>>>> a
>>>> ckTrace+0x24)
>>>> [0x260a0e]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(epic
>>>> s
>>>> S
>>>> t
>>>> ackTrace+0x4e)
>>>> [0x24f420]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(cant
>>>> P
>>>> r
>>>> o
>>>> ceed+0x50)
>>>> [0x17c532]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(d
>>>> b
>>>> G
>>>> e
>>>> tLink+0xb2)
>>>> [0x16e61f]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(d
>>>> b
>>>> P
>>>> r
>>>> ocess+0x1af)
>>>> [0x1a4b5b]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(i
>>>> o
>>>> c
>>>> B
>>>> uild_2+0x49b)
>>>> [0x1a4c0a]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(i
>>>> o
>>>> c
>>>> B
>>>> uild+0x3a)
>>>> [0x1a4c77]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(i
>>>> o
>>>> c
>>>> I
>>>> nit+0x17)
>>>> [0x1a53f7]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(i
>>>> o
>>>> c
>>>> I
>>>> nitCallFunc+0x17)
>>>> [0x24a271]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(iocs
>>>> h
>>>> B
>>>> o
>>>> dy+0xb41)
>>>> [0x24aa25]:
>>>> /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(iocs
>>>> h
>>>> +
>>>> 0
>>>> x25)
>>>> [0x804c54d]: ./bin/linux-x86/ioc(main+0x1d)
>>>> [0x29ace6]: /lib/libc.so.6(__libc_start_main+0xe6)
>>>> [0x804bb61]: ./bin/linux-x86/ioc(_start+0x21)
>>>>
>>>> The record source code looks very similar to the standard mbbiDirect. I have checked structures' definitions, the EPICS export calls, record support routines, etc. in some other standard records. I'm not sure what I could be missing here.
>>>>
>>>> Best Regards,
>>>> Abdalla.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: tech-talk-bounces@aps.anl.gov 
>>>> [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Dirk Zimoch
>>>> Sent: Monday, October 01, 2018 10:10 AM
>>>> To: tech-talk@aps.anl.gov
>>>> Subject: Re: Stream device does not recognize a custom record type
>>>>
>>>> Hello Abdalla,
>>>>
>>>> In the stack trace you can see a problem with a NULL pointer access in your record support code. No StreamDevice involved here at all.
>>>>
>>>> Are you sure you load the correct dbd file? Loading a dbd file of a wrong EPICS base version is a common cause for crashes.
>>>>
>>>> I will try your code. Maybe I find something....
>>>>
>>>> Dirk
>>>>
>>>> On 30.09.2018 14:41, Abdalla  Ahmad wrote:
>>>>> Hi
>>>>>
>>>>> One of our IOC servers currently has the following setup:
>>>>>
>>>>> OS: SL 6.4 32-bit
>>>>>
>>>>> EPICS: 3.15.5 (previously 3.14.12.3)
>>>>>
>>>>> synApps built from assemble_synApps script (previously 5.6)
>>>>>
>>>>> Stream device R2-7-7a (Previously 2-5-1)
>>>>>
>>>>> This IOC has some records that use a custom record called "mbbi2"
>>>>> which was created here at SESAME by an engineer used to work here.
>>>>> The purpose of this record is to provide alarm severity for each 
>>>>> bit of the standard mbbiDirect, otherwise they are the same.
>>>>>
>>>>> The problem is integrating this record with the stream device driver.
>>>>> What we found after searching the synApps 5.6 setup:
>>>>>
>>>>> 1.Adding MBBI2 definition to the stream device configure/RELEASE.
>>>>>
>>>>> 2.Including mbbi2.dbd and mbbi library in streamApp/Makefile.
>>>>>
>>>>> 3.Having mbbi2Record.h and devmbbiStream.c sources in the 
>>>>> StreamDevice/src
>>>>>
>>>>> 4.Adding mbbi2 to RECORDS in StreamDevice/src/CONFIG_STREAM
>>>>>
>>>>> That's all under base 3.14.12.3, we are not sure if something else 
>>>>> is missing under 3.15.5 setup. With all these steps, the new 
>>>>> stream device driver compiles with mbbi2 definitions (dbd file, 
>>>>> ldd command), but when running the IOC it immediately crashes with 
>>>>> segmentation fault. I enabled core dumps, loaded the core dump 
>>>>> into gdb, backtrace it and I got this
>>>>>
>>>>> Core was generated by `./bin/linux-x86/ioc iocBoot/ioc/st.cmd'.
>>>>>
>>>>> Program terminated with signal 11, Segmentation fault.
>>>>>
>>>>> #0  cvt_st_us (from=0xb <Address 0xb out of bounds>, to=0x87f9354,
>>>>> paddr=0x0) at ../../../src/ioc/db/dbFastLinkConv.c:161
>>>>>
>>>>> 161     if (*from == 0) {
>>>>>
>>>>> Missing separate debuginfos, use: debuginfo-install
>>>>> glibc-2.12-1.107.el6_4.5.i686 libgcc-4.4.7-3.el6.i686
>>>>> libstdc++-4.4.7-3.el6.i686 ncurses-libs-5.7-3.20090208.el6.i686
>>>>> net-snmp-libs-5.5-44.el6_4.4.i686 openssl-1.0.0-27.el6_4.2.i686
>>>>> pcre-7.8-6.el6.i686 readline-6.0-4.el6.i686 zlib-1.2.3-29.el6.i686
>>>>>
>>>>> (gdb) backtrace
>>>>>
>>>>> #0  cvt_st_us (from=0xb <Address 0xb out of bounds>, to=0x87f9354,
>>>>> paddr=0x0) at ../../../src/ioc/db/dbFastLinkConv.c:161
>>>>>
>>>>> #1  0x00848d0f in dbConstLoadLink (plink=0x87f9338, dbrType=4,
>>>>> pbuffer=0x87f9354) at ../../../src/ioc/db/dbLink.c:108
>>>>>
>>>>> #2  dbLoadLink (plink=0x87f9338, dbrType=4, pbuffer=0x87f9354) at
>>>>> ../../../src/ioc/db/dbLink.c:475
>>>>>
>>>>> #3  0x008556fc in recGblInitConstantLink (plink=0x87f9338, 
>>>>> dbftype=4,
>>>>> pdest=0x87f9354) at ../../../src/ioc/db/recGbl.c:167
>>>>>
>>>>> #4  0x006c14f8 in init_record (prec=0x87f91c0, pass=1) at
>>>>> ../mbbi2Record.c:153
>>>>>
>>>>> #5  0x008719c7 in doInitRecord1 () at
>>>>> ../../../src/ioc/misc/iocInit.c:543
>>>>>
>>>>> #6  iterateRecords () at ../../../src/ioc/misc/iocInit.c:472
>>>>>
>>>>> #7  initDatabase () at ../../../src/ioc/misc/iocInit.c:551
>>>>>
>>>>> #8  iocBuild_2 () at ../../../src/ioc/misc/iocInit.c:148
>>>>>
>>>>> #9  0x00871c0a in iocBuild () at
>>>>> ../../../src/ioc/misc/iocInit.c:187
>>>>>
>>>>> #10 0x00871c77 in iocInit () at ../../../src/ioc/misc/iocInit.c:99
>>>>>
>>>>> #11 0x008723f7 in iocInitCallFunc (args=0x878ba80) at
>>>>> ../../../src/ioc/misc/miscIocRegister.c:25
>>>>>
>>>>> #12 0x00a11271 in iocshBody (pathname=<value optimized out>, 
>>>>> commandLine=0x0, macros=0x0) at
>>>>> ../../../src/libCom/iocsh/iocsh.cpp:815
>>>>>
>>>>> #13 0x00a11a25 in iocsh (pathname=0xbfe125f0 "iocBoot/ioc/st.cmd") 
>>>>> at
>>>>> ../../../src/libCom/iocsh/iocsh.cpp:883
>>>>>
>>>>> #14 0x0804c97d in main (argc=2, argv=0xbfe10514) at
>>>>> ../iocMain.cpp:17
>>>>>
>>>>> The IOC was complaining about DTYP and BFST fields which it cannot 
>>>>> set their values, we looked up the mbbi2.dbd and found out 
>>>>> deprecated values for the promotgroup. We are not sure if this is 
>>>>> the problem or not but we changed all promotegroup to the new 
>>>>> values found in base
>>>>> 3.15.5 app developer guide, the IOC accepted the DTYP field but 
>>>>> still unable to set . Still facing the same segmentation fault with the same backtrace.
>>>>>
>>>>> Here is an example mbbi2 record:
>>>>>
>>>>> record(mbbi2, "$(SYSTEM):getStatusWord")
>>>>>
>>>>> {
>>>>>
>>>>>          field(DESC, "Reads status word")
>>>>>
>>>>>          field(SCAN, "2 second")
>>>>>
>>>>>          field(DTYP, "stream")
>>>>>
>>>>>          field(INP, "@work-microwave-ssx.proto getStatusWord
>>>>> $(CONTROLLER)")
>>>>>
>>>>>          field(VAL, "0")
>>>>>
>>>>>          field(PINI, "YES")
>>>>>
>>>>>          field(B0ST, "Standby mode")        field(B0ZSV, 
>>>>> "NO_ALARM") field(B0OSV, "NO_ALARM")
>>>>>
>>>>>          field(B1ST, "PLO PLL")             field(B1ZSV, 
>>>>> "NO_ALARM") field(B1OSV, "MINOR")
>>>>>
>>>>>          field(B2ST, "Reference PLL")       field(B2ZSV, 
>>>>> "NO_ALARM") field(B2OSV, "MAJOR")
>>>>>
>>>>>          field(B3ST, "Reference PLL")       field(B3ZSV, 
>>>>> "NO_ALARM") field(B3OSV, "MINOR")
>>>>>
>>>>>          field(B4ST, "Level Control")       field(B4ZSV, 
>>>>> "NO_ALARM") field(B4OSV, "NO_ALARM")
>>>>>
>>>>>          field(B5ST, "MW")                  field(B5ZSV, 
>>>>> "NO_ALARM") field(B5OSV, "MINOR")
>>>>>
>>>>>          field(B6ST, "OCXO/TCXO")           field(B6ZSV, 
>>>>> "NO_ALARM") field(B6OSV, "NO_ALARM")
>>>>>
>>>>>          field(B7ST, "RF OFF")              field(B7ZSV, 
>>>>> "NO_ALARM") field(B7OSV, "NO_ALARM")
>>>>>
>>>>>          field(B8ST, "Oven status (OCXO)")  field(B8ZSV, 
>>>>> "NO_ALARM") field(B8OSV, "NO_ALARM")
>>>>>
>>>>>          field(B9ST, "Main synthesizer")    field(B9ZSV, 
>>>>> "NO_ALARM") field(B9OSV, "MAJOR")
>>>>>
>>>>>          field(BAST, "VHF synthesizer")     field(BAZSV, 
>>>>> "NO_ALARM") field(BAOSV, "MAJOR")
>>>>>
>>>>>          field(BBST, "Fine synthesizer")    field(BBZSV, 
>>>>> "NO_ALARM") field(BBOSV, "MAJOR")
>>>>>
>>>>>          field(BCST, "DBLR-Status (SSX-3)") field(BCZSV, 
>>>>> "NO_ALARM") field(BCOSV, "MAJOR")
>>>>>
>>>>>          field(BDST, "Summarized alarm")    field(BDZSV, 
>>>>> "NO_ALARM") field(BDOSV, "MAJOR")
>>>>>
>>>>>          field(BEST, "Reference-PLL")       field(BEZSV, 
>>>>> "NO_ALARM") field(BEOSV, "MAJOR")
>>>>>
>>>>>          field(BFST, "MW PLL")              field(BFZSV, 
>>>>> "NO_ALARM") field(BFOSV, "MAJOR")
>>>>>
>>>>> }
>>>>>
>>>>> Sorry for any misinformation, all our findings were the result of 
>>>>> comparing between the two EPICS bases and the two synApps collections.
>>>>> Attached is the record's source code stream device interface files.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Abdalla Ahmad
>>>>>
>>>>> Control Engineer
>>>>>
>>>>> SESAME
>>>>>
>>>>> Allan, Jordan.
>>>>>
>>>>> Tel: (+962-5) 3511348 , ext. 265
>>>>>
>>>>> Fax: (+962-5) 3511423
>>>>>
>>>>> Mob: (+962-7)88183296
>>>>>
>>>>> www.sesame.org.jo <http://www.sesame.org.jo/>
>>>>>