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(epicsBackTrace+0x24)
[0x260a0e]: /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(epicsStackTrace+0x4e)
[0x24f420]: /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(cantProceed+0x50)
[0x17c532]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(dbGetLink+0xb2)
[0x16e61f]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(dbProcess+0x1af)
[0x1a4b5b]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(iocBuild_2+0x49b)
[0x1a4c0a]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(iocBuild+0x3a)
[0x1a4c77]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(iocInit+0x17)
[0x1a53f7]: /home/control/epics/base-3.15.5/lib/linux-x86/libdbCore.so.3.15.5(iocInitCallFunc+0x17)
[0x24a271]: /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(iocshBody+0xb41)
[0x24aa25]: /home/control/epics/base-3.15.5/lib/linux-x86/libCom.so.3.15.5(iocsh+0x25)
[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: [email protected] [mailto:[email protected]] On Behalf Of Dirk Zimoch
Sent: Monday, October 01, 2018 10:10 AM
To: [email protected]
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/>
>
- Replies:
- Re: Stream device does not recognize a custom record type Dirk Zimoch
- References:
- Stream device does not recognize a custom record type Abdalla Ahmad
- Re: Stream device does not recognize a custom record type Dirk Zimoch
- Navigate by Date:
- Prev:
Re: Stream device does not recognize a custom record type Dirk Zimoch
- Next:
Re: Stream device does not recognize a custom record type Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Stream device does not recognize a custom record type Dirk Zimoch
- Next:
Re: Stream device does not recognize a custom record type Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|