Experimental Physics and
Industrial Control System

"Bertrand H.J. Biritz" <[email protected]> · Mon, 22 Oct 2007 21:36:07 -0700

Sorry for the sudden silence. Last week was really busy for me.
I realized I had not followed Eric's suggestion fully of modifying the
Makefile by adding the Com. When I tried this I actually got gcc from
Apple to give me an error message.

Now I don't remember what the error message was exactly since in the
mean time I have had to return my PowerBook to Apple for repair (it
would freeze on me at least twice a day).
Once I get it back I will try once more - although the test might be
different since I am one of those fanboys who will install 10.5
immediately when it comes out on Friday :)
Thanks for all the help,
Bertrand
Quoting Eric Norum <[email protected]>:
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__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
()

#6 0x8fe0ba68 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE
()

#7 0x8fe0b9f8 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE
()

#8 0x8fe0b9f8 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE
()

#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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System