search

keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

atexit handlers crash C++ runtime #169

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 classi...@floodgap.com on 10 Jul 2012 at 5:17

GoogleCodeExporter commented 9 years ago 
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 classi...@floodgap.com on 10 Jul 2012 at 5:19

GoogleCodeExporter commented 9 years ago 
s/gcc/gdb/

Original comment by classi...@floodgap.com on 10 Jul 2012 at 5:19

GoogleCodeExporter commented 9 years ago 
To confirm: 10.5Fx doesn't suffer from any problems like this.

Original comment by Tobias.N...@gmail.com on 10 Jul 2012 at 6:28

GoogleCodeExporter commented 9 years ago 
Do you build against the 10.4 SDK or the 10.5 SDK?

Original comment by classi...@floodgap.com on 10 Jul 2012 at 1:27

GoogleCodeExporter commented 9 years ago 
I built 14 and 15 against the 10.5 SDK only.

Original comment by Tobias.N...@gmail.com on 10 Jul 2012 at 8:01

GoogleCodeExporter commented 9 years ago 
No change in 17. We'll see if there is any difference after the compiler switch.

Original comment by classi...@floodgap.com on 19 Sep 2012 at 2:42

GoogleCodeExporter commented 9 years ago 
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 classi...@floodgap.com on 10 Dec 2012 at 1:49

GoogleCodeExporter commented 9 years ago 
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 Tobias.N...@gmail.com on 10 Dec 2012 at 8:08

GoogleCodeExporter commented 9 years ago 
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 Tobias.N...@gmail.com on 10 Dec 2012 at 8:40

Attachments:

GoogleCodeExporter commented 9 years ago 
Demonstrated that the linker bug exposed in issue 52 is in fact the cause of 
this crash.

Original comment by classi...@floodgap.com on 14 Dec 2012 at 2:27

GoogleCodeExporter commented 9 years ago 
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 classi...@floodgap.com on 21 Dec 2012 at 4:48