EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Fwd: crash when clearing link field
From: Andrew Johnson <[email protected]>
To: EPICS core-talk <[email protected]>
Date: Fri, 18 Jul 2014 11:33:57 -0500
If anybody has time to look into this please do and report back here,
Tim Mooney found a way to segfault a 3.14 IOC when using putNotify. I
have confirmed that this happens and can see the problem as Tim
describes it, but I don't know what the fix should be.

There is a live notify operation still outstanding when the second caput
changes the output link. The naive solution to this (have
dbCaCallbackProcess() do nothing if pdbCommon is NULL) does not result
in a putNotify completion being sent back to the client, which isn't
really acceptable and may leak memory.

I would like a fix for both 3.14 and 3.15 (which may be different since
putNotify was replaced with processNotify), but I can convert a 3.14 fix
into the 3.15 one.

- Andrew


-------- Original Message --------
Subject: 	crash when clearing link field
Date: 	Fri, 27 Jun 2014 16:52:26 -0500
From: 	Mooney, Tim M. <[email protected]>
To: 	Johnson, Andrew N. <[email protected]>



Hi Andrew,

I found something I thought you'd be interested in.  If a record
executes a put_callback link, and the link field is cleared while the
callback is outstanding, the ioc crashes immediately.  This happens both
on Linux and vxWorks, and with base 3.14 and 3.15.  When the link field
is cleared, dbCaTask() notices that a callback is outstanding on it, and
issues a complimentary completion callback: "if (callback)
callback(plinkPutCallback);"
According to gdb, the problem occurs when dbCaCallbackProcess() calls
dbScanLock(), and dbScanLock() executes the line "lockRecord
*plockRecord = precord->lset;", because precord==0.

Here's a database and caput commands that demonstrate the problem:

record(ao, "linkCrashAO") {
    field(DTYP, "Async Soft Channel")
    field(OUT, "linkCrashCO.A CA")
}
record(calcout, "linkCrashCO") {
    field(CALC, "0")
    field(ODLY, "10")
}


caput -c -w20 linkCrashAO.PROC 1
caput linkCrashAO.OUT ""

Tim



Navigate by Date:
Prev: Re: [Merge] lp:~epics-core/epics-base/ioc-shutdown2 into lp:epics-base Andrew Johnson
Next: isfinite() on Linux Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Codeathon Projects J. Lewis Muir
Next: isfinite() on Linux Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 22 Jul 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·