Closed Bug 566614 Opened 15 years ago Closed 13 years ago

Crash [@dlopen ] on Thunderbird startup

Categories

(Core :: Widget: Cocoa, defect)

1.9.2 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Usul, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

0 @0x8fe0cb71 1 @0x8fe01a97 2 @0x8fe04af7 3 @0x8fe1058a 4 @0x8fe051ad 5 @0x8fe0bc32 6 libSystem.B.dylib dlopen 7 thunderbird-bin nsAppShell::Init widget/src/cocoa/nsAppShell.mm:433 8 thunderbird-bin nsAppShellInit widget/src/xpwidgets/nsAppShellSingleton.h:74 9 libxpcom_core.dylib nsGenericModule::Initialize nsGenericFactory.cpp:273 10 libxpcom_core.dylib nsGenericModule::GetClassObject nsGenericFactory.cpp:361 11 libxpcom_core.dylib nsFactoryEntry::GetFactory xpcom/components/nsComponentManager.cpp:3706 12 libxpcom_core.dylib nsComponentManagerImpl::CreateInstance xpcom/components/nsComponentManager.cpp:1593 13 libxpcom_core.dylib nsComponentManagerImpl::GetService xpcom/components/nsComponentManager.cpp:1901 14 libxpcom_core.dylib nsGetServiceByCID::operator const nsComponentManagerUtils.cpp:83 15 libxpcom_core.dylib nsCOMPtr_base::assign_from_gs_cid nsCOMPtr.cpp:114 16 thunderbird-bin nsChromeRegistry::CheckForOSAccessibility 17 thunderbird-bin ScopedXPCOMStartup::SetWindowCreator toolkit/xre/nsAppRunner.cpp:1231 18 thunderbird-bin XRE_main toolkit/xre/nsAppRunner.cpp:3277 19 thunderbird-bin main mail/app/nsMailApp.cpp:101 20 thunderbird-bin thunderbird-bin@0x2351 21 thunderbird-bin thunderbird-bin@0x2278 22 @0x0
Steven, this is crashing in dlopen in the code you added in bug 396680.
Blocks: 396680
Severity: normal → critical
Version: 1.9.1 Branch → 1.9.2 Branch
> Steven, this is crashing in dlopen in the code you added in bug 396680. Why do you say this? It's not apparent from the stack in comment #0. Please post a stack that shows what you say.
OK, now I see that the crash happens when code in nsAppShell::Init() tries to dlopen() an Apple system library: http://hg.mozilla.org/releases/mozilla-1.9.2/diff/ae68009f697c/widget/src/cocoa/nsAppShell.mm The crash isn't caused by my patch -- the call to dlopen() should just fail if this library is absent. But the call to dlopen() does seem to trigger it. Do we know how to reproduce these crashes?
If you're looking for the cause of the crashes at dlopen(), https://crash-stats.mozilla.com/report/index/c33d0fab-f7e8-4129-86ad-fd08d2100429 is clearly not the place to start -- it's not at all typical. I these are all caused by an Apple bug, which I might be able to work around if we could reproduce even one of the crashes at dlopen.
No longer blocks: 396680
> I these are all caused by an Apple bug I suspect these are all caused by an Apple bug.
Another possibility, I suppose, is that these crashes happen using dlopen() on a corrupt binary. Especially if the problem keeps happening on a given machine.
(In reply to comment #8) > Another possibility, I suppose, is that these crashes happen using dlopen() on > a corrupt binary. Especially if the problem keeps happening on a given > machine. It only happened once on my machine - so I have no STRs nor ways to easily reproduce.
Crash Signature: [@dlopen ]
You need to log in before you can comment on or make changes to this bug.