Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 5 May 2009 10:53:45 -0600

> 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.

On windows, the epicsShareAPI attribute defines a common (language neutral)
calling convention so that a function can be called directly from multiple
languages, and from rapid prototyping environments such as Visual Basic or
MATLAB.

On windows, the epicsShareFunc attribute is used to configure exports from
shareable libraries from within the source code.

Chris Timossi, at LBL, originally asked for both of these attribute for all
of the CA functions, and I accommodated his request at the time.

I think that over the years, the approach to CA function prototypes was
replicated in libCom where conceivably some of those functions might be
called from multiple languages. Later that approach was replicated also for
other DLLs where epicsShareAPI attribute is perhaps less appropriate. 

Jeff

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Wednesday, April 29, 2009 11:43 AM
> To: Tim Mooney; EPICS tech-talk; [email protected]; [email protected];
> [email protected]
> Subject: RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin; PROBLEM
> SOLVED
> 
> 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System