> 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.
- References:
- dbCaPutLinkCallback crash in 3.14.10 on cygwin Tim Mooney
- RE: dbCaPutLinkCallback crash in 3.14.10 on cygwin; PROBLEM SOLVED Mark Rivers
- Navigate by Date:
- Prev:
Looking for Allen-Bradley PLC-5 EPICS drivers Jane Richards
- Next:
RTEMS Survey Eric Norum
- 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:
Re: dbCaPutLinkCallback crash in 3.14.10 on cygwin; PROBLEM SOLVED Tim Mooney
- Next:
Debugging CAS-beacon crash Sue Witherspoon
- 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
|