Ah yes, it's coming back to me now.
That's why I had to add libCom to the beginning of the library
list --
to ensure that the constructors ran in the right order.
........did I mention that I really don't like C++......
On Oct 16, 2007, at 4:38 PM, Matthieu Bec wrote:
I had a vaguely similar issue on Linux. This thread on tech-talk
helped me resolve the problem:
http://www.aps.anl.gov/epics/tech-talk/2006/msg01325.php
Matthieu
Bertrand H.J. Biritz wrote:
Here is that output:
(gdb) run
Starting program: /usr/local/epics/extensions/bin/darwin-ppc/edm
Reading symbols for shared libraries ...++..+.++++...++++ done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000008
0x0021c7dc in epicsMutex::lock (this=0x1e6ecd0) at ../../../src/
libCom/osi/epicsMutex.cpp:118
118 epicsMutexOsdLock(pmutexNode->id);
(gdb) bt
#0 0x0021c7dc in epicsMutex::lock (this=0x1e6ecd0) at ../../../
src/libCom/osi/epicsMutex.cpp:118
#1 0x01e492f4 in ca_client_context::ca_client_context
(this=0x2400b20, enablePreemptiveCallback=false) at ../../../
include/epicsGuard.h:68
#2 0x01e2e69c in ca_context_create
(premptiveCallbackSelect=ca_disable_preemptive_callback) at ../
access.cpp:205
#3 0x018a23f0 in EPICS_PV_Factory::EPICS_PV_Factory
(this=0x2400930) at ../epics_pv_factory.cc:64
#4 0x018d525c in __static_initialization_and_destruction_0
(__initialize_p=31911120, __priority=37752208) at ../
pv_factory.cc:59
#5 0x8fe15608 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11Li
nkContextE ()
#6 0x8fe0ba68 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContext
E ()
#7 0x8fe0b9f8 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContext
E ()
#8 0x8fe0b9f8 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContext
E ()
#9 0x8fe0d5ec in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#10 0x8fe02cb4 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#11 0x00002904 in _start ()
#12 0x000027d0 in start ()
On Oct 16, 2007, at 1:19 PM, Mark Rivers wrote:
Type "bt" at the gdb prompt to get a stack trace and see what
function
you are in when the access fault occurs.
Mark
--
Matthieu Bec Gemini Observatory
Tel: +56 51 205785 c/o AURA, Casilla 603
Fax: +56 51 205650 La Serena, Chile
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793