Global destructors called for invalid objects on Darwin x86, but nowhere else.
Global destructors called for invalid objects on Darwin x86, but nowhere else.
- Subject: Global destructors called for invalid objects on Darwin x86, but nowhere else.
- From: "Kevin Harris" <email@hidden>
- Date: Tue, 11 Jul 2006 17:26:14 -0600
I have been trying to make the OpenWBEM project (www.openwbem.org) run
natively on Darwin i386. It already runs on the latest PPC version,
as well as many other platforms. I have run into issues with global
constructors and destructors. I apologize in advance for the length
of this message, and you can just read the next paragraph to get an
idea of what is going on. Any assistance would be greatly
appreciated.
I'll try to provide as many details as I can below, but for a quick
summary, I have two C++ files within a library where if there are any
non-trivial global constructors called within them, they will abort at
cleanup. This included any global data that is constructed but never
accessed, and does not seem to be dependent on the name of the object
or namespace that it is declared within (I've tried lots of
combinations).
Machine configuration:
Kernel: Darwin Kernel Version 8.7.1
Mac OS X: 10.4.7 Build 8J2135
xcode: 2.2.1 (also just upgraded to 2.3 and tried it)
I would like to create an example of how it breaks, but this project
is so large, and the error only occurs in one library (specifically
two files within that library), so it would take a lot of effort to
duplicate it in some simple code.
If anyone would like to assist (or just doesn't believe me), the
OpenWBEM module is at cvs.openwbem.org:/cvsroot/openwbem on branch
BRANCH_SECURITY.
Basically, everything seems to run correctly. When things exit (or
libraries get unloaded), the global destructors get called for that
library. These destructors start executing on what appears to be
invalid data. The strange part of this is that this happens to
everything within a file (including unused/untouched items added for
testing) if any of the global data in that file is accessed.
I first suspected that some form of stack smashing was occuring, but I
ran everything with the malloc debugging with the stack logging (and
every other runtime memory debugging option I could find) turned on,
and nothing showed up.
Several hours of peeking and poking through the debugger (I'll admit
that I don't track down these kinds of failures very often) led me to
two files that are having problems:
src/cimom/common/OW_CIMOMEnvironment.cpp and
src/cimom/common/OW_AuthorizerManager.cpp
The problem is most easy to locate when running the unit tests on
OW_ProviderManager and OW_ProviderMuxLoader (both of which call
functions that play with the CIMOMEnvironment global class). Removing
any objects with non-trivial global constructors from these two files
in the cimom common library seems to fix things.
Here's a sample stack trace from running test/unit/unitMain with
OW_ProviderManager as the sole argument, showing the destructors
calling functions on invalid objects:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000005
0x00132630 in OpenWBEM6::AtomicDecAndTest (v=@0x5) at
../../src/common/OW_AtomicOps.hpp:79
79 :"m" (v.val) : "memory");
(gdb) where
#0 0x00132630 in OpenWBEM6::AtomicDecAndTest (v=@0x5) at
../../src/common/OW_AtomicOps.hpp:79
#1 0x00132695 in OpenWBEM6::RefCount::decAndTest (this=0x5) at
../../src/common/OW_RefCount.hpp:64
#2 0x0013e2a0 in OpenWBEM6::COWIntrusiveReferenceRelease (p=0x1) at
../../src/common/OW_COWIntrusiveCountableBase.hpp:102
#3 0x05b3dd2c in
OpenWBEM6::COWIntrusiveReference<OpenWBEM6::String::ByteBuf>::~COWIntrusiveReference
(this=0x3eccaa8) at OW_COWIntrusiveReference.hpp:100
#4 0x05a5d171 in OpenWBEM6::String::~String (this=0x3eccaa8) at
OW_String.cpp:328
#5 0x03e022ed in OpenWBEM6::(anonymous namespace)::Node::~Node
(this=0x3eccaa8) at OW_CIMOMEnvironment.cpp:1264
#6 0x03dd9648 in __tcf_1 () at OW_CIMOMEnvironment.cpp:1287
#7 0x03dc8525 in cxa_atexit_wrapper ()
#8 0x90010cc1 in __cxa_finalize ()
#9 0x90010bc8 in exit ()
#10 0x00002a2a in _start (argc=2, argv=0xbfffd298, envp=0xbfffd2a4) at
/SourceCache/Csu/Csu-58.1.1/crt.c:272
#11 0x0000293d in start ()
Your stack trace (if you build/run this) will likely show a different
failure point in the same file, as my copy of that file has been
altered to remove all but the one non-trivial global constructor.
I don't believe there is a problem with the code, as this functions
properly with several compilers on many platforms and only breaks on
the x86 version of Darwin. The PPC version, with a much older xcode
and gcc3.3, seems to work fine, so it could be a gcc4 issue. The PPC
version also runs correctly with rosetta.
If anyone has any suggestions for things to check/fix, or could
actually apply their uber Mac debugging skills, I would really
appreciate it.
Thank you for your time.
-Kevin-
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden