"ABORT: imgCacheEntry release isn't thread-safe!" involving dock-menu quit

VERIFIED DUPLICATE of bug 529949

Status

()

Core
ImageLib
--
critical
VERIFIED DUPLICATE of bug 529949
8 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({assertion})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 421202 [details]
crash report for the abort

I think this happened after I selected "Quit" from the Dock menu.  Dock-menu Quit is known to be problematic for Firefox (see e.g. bug 384284), but this is the first I've heard of it triggering threadsafety aborts.

###!!! ABORT: imgCacheEntry release isn't thread-safe!: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /Users/jruderman/mozilla-central/modules/libpr0n/src/imgLoader.h, line 81

Comment 1

8 years ago
afaiu:
15  libSystem.B.dylib             	0x9765f8a4 exit + 33
16  com.apple.AppKit              	0x92c10002 -[NSApplication terminate:] + 1056

will never work properly.

I think what's happening is that we have a 'static' pointer to something which holds an imageCache thing.

But the static pointer expects to be shutdown/released from the proper thread.

What's happening is that exit is looping over all of those static objects and forcefully asking them to die, but some of them are owned by other threads, which are probably still very alive, and would be quite shocked to see their objects changed randomly by the main thread.

The fix (if possible) is for us to cause the 'please quit' message to let us unwind our stack properly.
We can't stop using [NSApplication terminate:] -- it's the OS that
calls it (under certain circumstances), not us.  We also can't simply
ignore the OS's calls (by for example by always returning
NSTerminateCancel from [NSApplicationDelegate
applicationShouldTerminate:]) -- otherwise quitting from the Dock menu
wouldn't work (as would other things that make the OS want to use
[NSApplication terminate:]).

The only way this bug and bug 384284 can be fixed is with a
substantial re-design of the browser's shutdown sequence.  Basically,
we need either a call that synchronously shuts down the browser
completely, or a callback that tells us the browser has finished
shutting down (from which we could call [NSApplication
replyToApplicationShouldTerminate:YES]).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 529949

Comment 4

8 years ago
sorry, i should have caught the dupe :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.