Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
- Subject: Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
- From: "William H. Schultz" <email@hidden>
- Date: Tue, 13 Jun 2006 10:24:11 -0700
- Resent-date: Tue, 13 Jun 2006 10:24:35 -0700
- Resent-from: "William H. Schultz" <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Xcode Users <email@hidden>
Retesting will have to wait a while, but the crash occurred even with
debug code. I have had dead code stripping turned off for quite some
time, as it has caused other issues in the past.
What I could tell from looking at the code is that there were two
statics, and the second one depended on the first one being
initialized first. So, it seemed like the first static was either
not being initialized, or it was not being initialized in the correct
location.
The excessively odd part of this is that the statics that were
causing the crash were defined in a separate dylib (shared by the app
and all bundles)--not in the bundles being loaded. The bundles did
make use of the objects that the statics were in, though.
Hank Schultz
http://www.cedrus.com/
On Jun 12, 2006, at 3:40 PM, Andy O'Meara wrote:
My best and only guess (without knowing wxWidgets) is that it
perhaps does
initialization in a constructor of a static object:
// snip
// foo.cpp
class AppInitter {
AppInitter() {
// Do important init stuff here
}
};
AppInitter sAppInitterInstance;
// snip
Because sAppInitterInstance is never referenced, if the linker is
set to
strip unreferenced static objects, the important init stuff will
never get
called. Try turning off all dead code stripping and see if the
crash goes
away.
We feel your pain!
andy
On 6/12/06 5:52 PM, "William H. Schultz" <email@hidden> wrote:
Okay, I got a similar crash when I upgraded to 10.3, but my issue was
when the bundle loads, so the atexit stuff didn't help any. I've
since reverted to Xcode 2.2.1, since we are close enough to a final
release that I probably shouldn't have updated anyway.
I didn't explicitly use any module initialization or deinitialization
functions. However, there were several static wxWidgets items that
were interdependent, and this is where the crash occurred. I don't
have the time right now to dive any further into what was going on,
but I was thrilled when I saw that other people were having similar
issues, so I figured I would at least mention mine.
Thanks,
Hank Schultz
http://www.cedrus.com/
On Jun 11, 2006, at 8:37 AM, Allen Cronce wrote:
Hi Jim,
Fire up the way back machine ;-)
Once upon a time there were the CALL_ON_LOAD/CALL_ON_UNLOAD pragmas.
These worked under CW for Mach-O executables.
I think in recent times these pragmas worked under Xcode/gcc. But
apparently there was a period where they where unimplemented, so
there
was an ugly work around using the SECTION pragma to force a function
reference into either the __mod_init_func or __mod_term_func
section of
the _DATA segment.
And in any case, the CALL_ON_[UN]LOAD pragmas are deprecated with
gcc 4.0:
http://developer.apple.com/qa/qa2005/qa1429.html
So the short answer is you're right. The only reasonable way to
specify
module init/term procs with today's tools is via
__attribute__((constructor)) and __attribute__((destructor)).
Best,
--
Allen Cronce
Jim Wintermyre wrote:
Allen Cronce wrote:
I would have thought that relying on atexit for cleanup of a
non-application executable could result in undefined behavior.
Because
you really don't have control over when your bundle is unloaded.
Shouldn't you use a module termination proc or "__attribute__
((destructor))" instead?
I've never found a way to to have a "module termination proc" for a
Mach-O bundle (we had them in the CFM days), so I thought
"__attribute__((destructor))" was the only way to go. Am I missing
something?
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40cedrus.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40soundspectrum.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden