Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Wed, 29 Apr 2009 13:29:34 -0500

Thanks, Mark.  I just verified that, with your fix, the sseq and
sCalcout records are no longer crashing the ioc when they wait for
completion.

Tim

Mark Rivers wrote:

Folks,



I found and fixed the problem with dbCaPutLinkCallback not working on win32-x86 and cygwin-x86.



The problem was calling conventions on the callbacks defined in src/db/dbCa.h



Here is a fix:



****

corvette:base-3.14.10/src/db>cvs diff
Index: dbCa.h
===================================================================
RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/db/dbCa.h,v
retrieving revision 1.14.2.3
diff -u -r1.14.2.3 dbCa.h

--- dbCa.h      9 Jul 2008 21:31:50 -0000       1.14.2.3
+++ dbCa.h      29 Apr 2009 17:35:50 -0000
@@ -20,7 +20,7 @@
 extern "C" {
 #endif



-typedef void (*dbCaCallback)(void *userPvt);

+typedef void (epicsShareAPI *dbCaCallback)(void *userPvt);
 epicsShareFunc void epicsShareAPI dbCaCallbackProcess(struct link *plink);



 epicsShareFunc void epicsShareAPI dbCaLinkInit(void);

****



This makes the calling convention defined for dbCaCallback agree with the definition for the function being called.



Note that this has always been a bug for win32-x86. However, it was not a problem for cygwin-x86 until R3.14.10 because epicsShareAPI did not do anything on cygwin-x86 prior to 3.14.10.



Note also that Andrew Johnson has a better fix, which is to remove the epicsShareAPI decorations from all of the functions, rather than adding the decoration to dbCaCallback. That will presumably be committed for the next release, but meanwhile this is an easy fix to apply to work around the problem.



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.




--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.


Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System