atexit handlers crash C++ runtime

[GoogleCodeExporter]

Starting with 15.

Current wallpaper in nsBrowserApp.cpp::main() is just to _Exit() and never let 
the function return, but this is clearly wrong.

Ben suggests this could be a symptom of a library being unloaded, but dyld with 
DYLD_PRINT_LIBRARIES shows nothing being unloaded at all. It could be a 
compiler problem also: https://bugzilla.redhat.com/show_bug.cgi?id=161061

This is shippable but it should be fixed as it is possibly a symptom of a 
larger problem.

Not an issue for 10-stable.

Original issue reported on code.google.com by [email protected] on 10 Jul 2012 at 5:17

• Blocked on: Switch to gcc 4.6.3 #52

[GoogleCodeExporter]

gcc's stack at time of crash is singularly unhelpful; it usually points to some 
objc class that has nothing to do with it and probably just happened to be in 
the memory range of the bad destructor or vtable. Currently it dies in 
CTGradient. If we hack gfx/2d/ to no longer build CTGradient.m, then it dies in 
NoOp. The only commonality is that all of the crashes occur after 
__cxa_finalize() gets called.

Original comment by [email protected] on 10 Jul 2012 at 5:19

[GoogleCodeExporter]

s/gcc/gdb/

Original comment by [email protected] on 10 Jul 2012 at 5:19

[GoogleCodeExporter]

To confirm: 10.5Fx doesn't suffer from any problems like this.

Original comment by [email protected] on 10 Jul 2012 at 6:28

[GoogleCodeExporter]

Do you build against the 10.4 SDK or the 10.5 SDK?

Original comment by [email protected] on 10 Jul 2012 at 1:27

[GoogleCodeExporter]

I built 14 and 15 against the 10.5 SDK only.

Original comment by [email protected] on 10 Jul 2012 at 8:01

[GoogleCodeExporter]

No change in 17. We'll see if there is any difference after the compiler switch.

Original comment by [email protected] on 19 Sep 2012 at 2:42

[GoogleCodeExporter]

http://www.cocoabuilder.com/archive/xcode/250486-xcode-2-3-breaks-bundle-static-
object-destruction-fuse-cxa-atexit-help.html (from issue 52)

Original comment by [email protected] on 10 Dec 2012 at 1:49

[GoogleCodeExporter]

I've got an idea related to this. The library and symbol loading API calls used 
in nsGlueLinkingOSX are officially deprecated since the days of 10.4 and Apple 
recommends the use of dlopen & co. The advantage with dlopen & co would be that 
the dylib can be closed using dlclose what hopefully would clean up well.

Original comment by [email protected] on 10 Dec 2012 at 8:08

[GoogleCodeExporter]

Here a patch that makes XPCOM use dlopen/dlclose/dlsym instead of the 
deprecated functions that don't provide a way to unload dylibs. It works at 
least on 10.5 .

Original comment by [email protected] on 10 Dec 2012 at 8:40

Attachments:

• XPCOM_dlopen.patch

[GoogleCodeExporter]

Demonstrated that the linker bug exposed in issue 52 is in fact the cause of 
this crash.

Original comment by [email protected] on 14 Dec 2012 at 2:27

• Now blocked on: Switch to gcc 4.6.3 #52

[GoogleCodeExporter]

And fixed by issue 52, so closing. If we need to back this to 17, we'll just 
force a relink using the MacPorts ld.

Original comment by [email protected] on 21 Dec 2012 at 4:48

• Changed state: Fixed