Firefox crash on exit when Webmail Notifier is installed

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Tomcat, Assigned: jst)

Tracking

({crash})

Trunk
x86
Mac OS X
crash
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Created attachment 300240 [details]
crash stack

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012917 Firefox/3.0b3pre

This is a follow up bug from Bug 414658.

After this patch was checked in, Firefox crash on exit when the Webmail Notifier Extension is installed and a Account was created with :

Assertion failure: !cx->thread || cx->thread == thread, at /debug/mozilla/js/src/jscntxt.c:177
./run-mozilla.sh: line 131: 43200 Trace/BPT trap          "$prog" ${1+"$@"}
Flags: blocking1.9?

Updated

11 years ago
Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
(Reporter)

Comment 1

11 years ago
peter, jst here are some steps to reproduce from Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008013009 Firefox/3.0b3pre

-> Create a new Profile (any old would do also i think)
-> Install the Extension https://addons.mozilla.org/en-US/firefox/addon/4490
-> Restart Firefox to enable this extension
-> Go into the Preference of this Extensions (worked here only with Tools -> Add-ons -> Webmail Notifer... Preference
-> Enter Data of a real or dummy account, add this account to the Webmail Notifier Account List 
-> Exit Firefox

Check the Debug Output....Assertion failure
(Assignee)

Comment 2

11 years ago
This looks like it's actually an age old bug. It's apparently harmless in release builds as nobody has found this to be a problem before, but it sure looks like this is an old bug.

Peterv and I looked into this, and here's what happens. The JS in the extension ends up registering a notification callback with our networking code, that callback happens on one of the network threads. All good so far. When that call comes through to that JS code on the network thread, XPConnect creates a safe context for that thread and runs the code there. Still all good. Then we shut down, and we end up in nsSocketTransportService::Shutdown(), which kills its thread. Here's where things start going wrong...

The basic problem is that the per thread data registered for the thread ends up being destroyed on the wrong thread. Per the headers in nspr, the per thread data destructor callback should happen on the thread the data belongs to, but that's not what's happening in this case. The network thread is destroyed on the main thread, and that leads to the per thread data being destroyed on the main thread, and that's what ends up resulting in the JS asserts that take us down in debug builds. In release builds we get lucky and don't notice.

Here's the important part of the stack:

...
#6  0x0399ff4f in xpc_ThreadDataDtorCB (ptr=0x8f48920)
    at ../../../../../mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:544
#7  0x003b605c in _PR_DestroyThreadPrivate (self=0x8f48150)
    at ../../../../mozilla/nsprpub/pr/src/threads/./prtpd.c:265
#8  0x003d3167 in _pt_thread_death_internal (arg=0x8f48150, callDestructors=1)
    at ../../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:833
#9  0x003d30c4 in _pt_thread_death (arg=0x8f48150)
    at ../../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:812
#10 0x003d2b03 in PR_JoinThread (thred=0x8f48150)
    at ../../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:600
#11 0x0033bad5 in nsThread::Shutdown (this=0x8f47ed8)
    at ../../../mozilla/xpcom/threads/nsThread.cpp:469
#12 0x03d0d92d in nsSocketTransportService::Shutdown (this=0x8f47848)
    at ../../../../mozilla/netwerk/base/src/nsSocketTransportService2.cpp:442
...

This all happens on the main thread. Seems like _PR_DestroyThreadPrivate() would've needed to be called before we get here. It could in theory be called by nsThreadManager::UndegisterCurrentThread(), which runs on the thread that's being unregisters (and before we get to the above stack), but nspr doesn't expose _PR_DestroyThreadPrivate().

Wan-Teh, this really sort of seems like a NSPR bug, PR_JoinThread() ends up calling into _PR_DestroyThreadPrivate() on the calling thread rather than the thread that's being destroyed etc.

Thoughts?
(Assignee)

Comment 3

11 years ago
Oh, and this is looks like it's not a problem on Win32, but it is on Linux and Mac OSX. pthread related more than likely...

Comment 4

11 years ago
Created attachment 300547 [details] [diff] [review]
Proposed patch

Could you test this patch?  Thanks for the clear analysis of the bug.
That fixes it for me.
(Assignee)

Comment 6

11 years ago
Fixes the problem for me as well.

Comment 7

11 years ago
Thanks for testing my patch.  timeless opened NSPR bug 414997 for this issue.
Depends on: 414997

Updated

11 years ago
Duplicate of this bug: 412338
(Reporter)

Comment 9

11 years ago
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9b4pre) Gecko/2008020717 Firefox/3.0b4pre- no crash with this extension.

-> fixed
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.