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: "Andy O'Meara" <email@hidden>
- Date: Tue, 13 Jun 2006 13:39:41 -0400
- Thread-topic: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
>
> 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.
>
>
I'm trying to understand what you mean... If you can sketch out what the
relationship of all your modules and how they load eachother with some
simplified code, perhaps it will be clearer to myself and others what may be
going on.
> 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