Tim,
I was able to reproduce the crash on cygwin-x86 with 3.14.10.
It worked fine on Linux.
But interestingly it also crashes on win32-x86.
I put the following commands in st.cmd to do the test:
dbLoadRecords("./mooney.db", "P=epics:")
iocInit()
dbpf("epics:aoCallbackTest.OUT", "epics:aiExample.PREC CA")
dbtr("epics:aoCallbackTest")
Where mooney.db is the database you posted.
On both cygwin-x86 and win32-x86 the dbtr command prints out the record and then the fault message appears.
The fact that it crashes with both the gcc and VC compilers suggests something is wrong with the source code.
Mark
________________________________
From: [email protected] on behalf of Tim Mooney
Sent: Fri 4/24/2009 3:13 PM
To: EPICS tech-talk
Subject: dbCaPutLinkCallback crash in 3.14.10 on cygwin
Dear folks,
Has anyone else run into problems with 3.14.10's dbCaPutLinkCallback on cygwin?
When I run it, it crashes the ioc every time. Using an IOC directory made by
makeBaseApp, I load the following database:
record(ao,"$(P)aoCallbackTest") {
field(DTYP, "Async Soft Channel")
}
set $(P)aoCallbackTest.OUT to any other PV that exists in the example ioc,
which in my case was "mooneyHost:aiExample.PREC CA" (note that the "CA"
attribute is required for the link actually to perform as an
"Async Soft Channel"--i.e., to call dbCaPutLinkCallback()). The ioc
crashes reliably, with a segmentation fault, when $(P)aoCallbackTest is
processed. It creates the following file, of which I understand only the
last three words:
------myexample.exe.stackdump-----
Exception: STATUS_ACCESS_VIOLATION at eip=0085AEEA
eax=00000000 ebx=19B3CA30 ecx=19B3C804 edx=00000000 esi=0052D940 edi=19B3CA59
ebp=0045300E esp=19B3C9D4
program=C:\cygwin\home\mooney\epics\example\bin\cygwin-x86\myexample.exe, pid
4644, thread unknown (0x153C)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0045300E 0085AEEA (A845C700, 00000001, 050F1DE8, 838CEB00)
6 [unknown (0x153C)] myexample 4644 _cygtls::handle_exceptions: Error
while dumping state (probably corrupted stack)
----------------------------------
In other testing of dbCaPutLinkCallback (using custom record types such
as sseq and sCalcout, on cygwin with 3.14.10), I've noticed that the crash
never occurs until after the completion callback, after the record has called
recGblFwdLink, and after that function has returned. I haven't gone back to
testing against 3.14.8.2, but I'm pretty sure I would have noticed this if
it had been occurring.
Also, the problem does not occur when I use ca_array_put_callback() via code
other than dbCaPutLinkCallback. (The sscan and swait records use recDynLink
to do put callbacks, and they are not failing.)
I don't see this problem on solaris or vxWorks, and I don't think it's happening
on linux either.
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.
- Replies:
- RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers
- References:
- dbCaPutLinkCallback crash in 3.14.10 on cygwin Tim Mooney
- Navigate by Date:
- Prev:
dbCaPutLinkCallback crash in 3.14.10 on cygwin Tim Mooney
- Next:
RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers
- 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:
dbCaPutLinkCallback crash in 3.14.10 on cygwin Tim Mooney
- Next:
RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers
- 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
|