site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hUXHxg6TBMiUc6JbbiB8Ti/PoRnipJibxiHYmIBFSKz42IFZNHc+yQ61Z18uGqhxYsaSOLu8nsfECmfyU1VLajy12xidrWmqTkEAW52l3lf4n+n1nRDyeYDbVOOkTFWpnx57BsW+wZr+RIkoYxjsH/CqMSom5VJaVHlsHxwg3KA= 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com