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  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin
From: "Mark Rivers" <[email protected]>
To: "Tim Mooney" <[email protected]>, "EPICS tech-talk" <[email protected]>
Date: Tue, 28 Apr 2009 13:02:56 -0500
I have done some more testing.  Under 3.14.10 the dbtr command on the record doing the putCalback occassionally works with both win32-x86 and cygwin-x86.  But if it is done a few times it always crashes.
 
When I run the bin/win32x-86/example.exe application and it crashes I get the Windows dialog box asking me if I want to report the problem to Microsoft, which allows one to start the Visual Studio debugger.  I can do that, but because the application was built without a symbol table, the trace is just in assembly code.
 
So I then built EPICS base and the example application for the win32-x86-debug architecture.  I built it with SHARED_LIBRARIES=NO and STATIC_BUILD=YES, as I do for the non-debug version.  Everything builds fine.  However, when I run it and it crashes, it just silently returns me to the shell prompt, it does not produce a dialog box with the option to open the debugger!  So the debug version is even less useful for debugging than the non-debug version.
 
What am I doing wrong?
 
Thanks,
Mark
 

________________________________

From: Mark Rivers
Sent: Sun 4/26/2009 8:54 AM
To: Tim Mooney; EPICS tech-talk
Subject: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin


Tim,
 
I've now tested the same example application building with 3.14.8.2.
 
Works OK on linux-x86 and cygwin-x86.
 
It crashes on win32-x86 with the following (not very helpful) error:
 
Unhandled exception at 0x7c90100b in example.exe: 0xC0000005: Access violation reading location 0xbda006db.
 
So 3.14.10 crashes on both cygwin-x86 and win32-x86, 3.14.8.2 crashes only on win32-x86.
 
Mark
 

________________________________

From: Mark Rivers
Sent: Fri 4/24/2009 4:47 PM
To: Tim Mooney; EPICS tech-talk
Subject: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin


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.




References:
dbCaPutLinkCallback crash in 3.14.10 on cygwin Tim Mooney
RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers
RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers

Navigate by Date:
Prev: linux ioc problem John Sinclair
Next: Re: linux ioc problem Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin Mark Rivers
Next: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin; PROBLEM SOLVED Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·