EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: seg fault in sseq record when using AfterN option
From: "Pearson, Matthew R." <[email protected]>
To: "[email protected] list" <[email protected]>
Date: Fri, 16 Jan 2015 20:03:13 +0000
Hi,

I found an issue with using the 'AfterN' settings for the 'WAIT' fields in the sseq record. My record looks like this:

record(sseq, "BL16B:Det:ADnED:Stop")
{
  field(DOL1, "0")
  field(DOL2, "1")
  field(DOL3, "1")
  field(LNK1, "BL16B:Det:ADnED:DesiredState CA")
  field(LNK2, "BL16B:Det:N1:Stop.PROC CA")
  field(LNK3, "BL16B:Det:M1:Stop.PROC CA")
  field(WAIT1, "After3")
  field(WAIT2, "After3")
  field(WAIT3, "Wait")
  field(FLNK, "BL16B:Det:ADnED:State")
}

Which should mean that all 3 links are processed in one go, and then we wait for completion on all links. Does that look like correct usage?

What happened was that the callback from LNK1 returned before LNK3 could be processed for the first time. This caused the putCallbackCB function to be called, which calls processNextLink. Then processNextLink was called for LNK3 as normal, and then an additional time due to the first completed callback. This results in processCallback being called twice for the same link, the second one of which fails because pcb->index has been incremented out of range. 

I switched to configuring the record like this, which works ok:

record(sseq, "$(P):Stop")
{
  field(DOL1, "0")
  field(DOL2, "1")
  field(DOL3, "1")
  field(LNK1, "$(P):DesiredState CA")
  field(LNK2, "$(ADNED1):Stop.PROC CA")
  field(LNK3, "$(ADNED2):Stop.PROC CA")
  field(WAIT1, "Wait")
  field(WAIT2, "Wait")
  field(WAIT3, "Wait")
  field(FLNK, "$(P):State")
}

This waits for completion on each link, before processing the next one.

I managed to get a core dump:

(gdb) bt
#0  0x00007f40dca51568 in processCallback (pCallback=0x3205260) at ../sseqRecord.c:621
#1  0x00007f40ddd4cc1f in callbackTask (arg=0x7f40ddf67388) at ../callback.c:95
#2  0x00007f40df2563ce in start_routine (arg=0x1cf93f0) at ../../../src/libCom/osi/os/posix/osdThread.c:385
#3  0x00007f40da5f09d1 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f40da8ee9dd in clone () from /lib64/libc.so.6


(gdb) frame 0
#0  0x00007f40dca51568 in processCallback (pCallback=0x3205260) at ../sseqRecord.c:621

621  if (plinkGroup->dol_field_type == DBF_unknown)

(gdb) info locals
pR = 0x242b150
pcb = 0x3205260
plinkGroup = 0x0
status = 0
did_putCallback = 0
n_elements = 1
d = 1.5019682589127563e-316
str = "P\335\356\"@\177\000\000\035\006\324\335@\177\000\000`A\006\350?\177\000\000 \307B\002\000\000\000\000\240m\006\350?\177\000"

(gdb) print pcb->index
$21 = 3
(gdb) print pcb->plinkGroups[0]
$22 = (struct linkGroup *) 0x242b368
(gdb) print pcb->plinkGroups[1]
$23 = (struct linkGroup *) 0x242b420
(gdb) print pcb->plinkGroups[2]
$24 = (struct linkGroup *) 0x242b4d8
(gdb) print pcb->plinkGroups[3]
$25 = (struct linkGroup *) 0x0

 
(gdb) print pcb->plinkGroups[0]->waiting
$2 = 0
(gdb) print pcb->plinkGroups[1]->waiting
$3 = 1
(gdb) print pcb->plinkGroups[2]->waiting
$4 = 1


Here is the debug printout from the sseq record:

sseq: process(BL16B:Det:ADnED:Start) pact = 0
sseq:processNextLink(BL16B:Det:ADnED:Start) looking for work to do, index = 0, abort=0
sseq:processCallback(BL16B:Det:ADnED:Start) entry
sseq:processCallback(BL16B:Det:ADnED:Start) processing field index 0
sseq:processCallback: lnk_field_type = 5 (DBF_LONG)
sseq:processCallback: calling dbCaPutLinkCallback
sseq:processNextLink(BL16B:Det:ADnED:Start) looking for work to do, index = 1, abort=0
sseq:processCallback(BL16B:Det:ADnED:Start) entry
sseq:processCallback(BL16B:Det:ADnED:Start) processing field index 1
sseq:processCallback: lnk_field_type = 1 (DBF_CHAR)
sseq:processCallback: n_elements=1
sseq:processCallback: calling dbCaPutLinkCallback for DBF_CHAR
sseq:processNextLink(BL16B:Det:ADnED:Start) looking for work to do, index = 2, abort=0
sseq:putCallbackCB: entry
sseq:putCallbackCB: Got callback for link 0 (0..9)
sseq:processNextLink(BL16B:Det:ADnED:Start) looking for work to do, index = 2, abort=0
sseq:processCallback(BL16B:Det:ADnED:Start) entry
sseq:processCallback(BL16B:Det:ADnED:Start) processing field index 2
sseq:processCallback: lnk_field_type = 1 (DBF_CHAR)
sseq:processCallback: n_elements=1
sseq:processCallback: calling dbCaPutLinkCallback for DBF_CHAR
sseq:processNextLink(BL16B:Det:ADnED:Start) looking for work to do, index = 3, abort=0
sseq:processCallback(BL16B:Det:ADnED:Start) entry
sseq:processCallback(BL16B:Det:ADnED:Start) processing field index 3


Cheers,
Matt




Data Acquisition and Control Engineer
Spallation Neutron Source
Oak Ridge National Lab







Navigate by Date:
Prev: RE: Alarm annunciation with ALH and other PC based systems Elder Matias
Next: how to choose port of digitizer for IOC? Ana Malagon
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Support for Mercury iTC tom.cobb
Next: how to choose port of digitizer for IOC? Ana Malagon
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·