414745 - Firefox crash on exit when Webmail Notifier is installed

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: 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+"$@"}

Comment 1

[Carsten Book [:Tomcat]]

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

Comment 2

[Johnny Stenback (:jst)]

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?

Comment 3

[Johnny Stenback (:jst)]

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

[Wan-Teh Chang]

Attachment: Proposed patch

Could you test this patch?  Thanks for the clear analysis of the bug.

Comment 5

[Peter Van der Beken [:peterv]]

That fixes it for me.

Comment 6

[Johnny Stenback (:jst)]

Fixes the problem for me as well.

Comment 7

[Wan-Teh Chang]

Thanks for testing my patch.  timeless opened NSPR bug 414997 for this issue.

Comment 9

[Carsten Book [:Tomcat]]

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