411743 - Steps to reproduce from Bug 402749 crash Mac and Linux Debug Builds

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[Carsten Book [:Tomcat]]

Attachment: crash stack

During the verification of Bug 402479 my Debug Build crashs.
This crash was also reported in Bug 408601

Another Crash stack is https://bugzilla.mozilla.org/attachment.cgi?id=295994

Steps to reproduce:
1. Get an https error page by loading https://dave.sni.velox.ch/.
2. Click the "Or you can add an exception..." link.
3. Click the "Add exception" button.
4. Press Esc to close the dialog.
5. Cmd+Q.

Apple Crash Report:

#
Date/Time:      2008-01-10 11:42:55.440 -0800
#
OS Version:     10.4.11 (Build 8S2167)
#
Report Version: 4
#
 
#
Command: firefox-bin
#
Path:    ./firefox-bin
#
Parent:  sh [3516]
#
 
#
Version: 3.0b3pre (3.0b3pre)
#
 
#
PID:    3522
#
Thread: 0
#
 
#
Exception:  EXC_BREAKPOINT (0x0006)
#
Code[0]:    0x00000002
#
Code[1]:    0x00000000
#
 
#
 
#
Thread 0 Crashed:
#
0   libmozjs.dylib              0x0146e706 JS_Assert + 66 (jsutil.c:63)
#
1   libmozjs.dylib              0x013ba279 js_SetContextThread + 155 (jscntxt.c:178)
#
2   libmozjs.dylib              0x013b1680 JS_SetContextThread + 60 (jsapi.c:5658)
#
3   libxpconnect.dylib          0x13038bfe XPCJSContextStack::~XPCJSContextStack [in-charge deleting]() + 56 (xpcthreadcontext.cpp:61)
#
4   libxpconnect.dylib          0x13038171 XPCPerThreadData::Cleanup() + 151 (xpcthreadcontext.cpp:487)
#
5   libxpconnect.dylib          0x130382b6 XPCPerThreadData::~XPCPerThreadData [in-charge]() + 52 (xpcthreadcontext.cpp:500)
#
6   libxpconnect.dylib          0x13038399 xpc_ThreadDataDtorCB(void*) + 41 (xpcthreadcontext.cpp:532)
#
7   libnspr4.dylib              0x005b489d _PR_DestroyThreadPrivate + 193 (prtpd.c:266)
#
8   libnspr4.dylib              0x005d1f31 _pt_thread_death_internal + 165 (ptthread.c:834)
#
9   libnspr4.dylib              0x005d1e8a _pt_thread_death + 25 (ptthread.c:813)
#
10  libnspr4.dylib              0x005d1905 PR_JoinThread + 241 (ptthread.c:600)
#
11  libpipnss.dylib             0x3cc47af8 nsPSMBackgroundThread::requestExit() + 120 (nsPSMBackgroundThread.cpp:98)
#
12  libpipnss.dylib             0x3cc4fae0 nsNSSComponent::DoProfileChangeNetTeardown() + 36 (nsNSSComponent.cpp:2320)
#
13  libpipnss.dylib             0x3cc57232 nsNSSComponent::Observe(nsISupports*, char const*, unsigned short const*) + 1992 (nsNSSComponent.cpp:2069)
#
14  libxpcom_core.dylib         0x016b2f7b nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) + 97 (nsObserverList.cpp:127)
#
15  libxpcom_core.dylib         0x016b3625 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) + 333 (nsObserverService.cpp:184)
#
16  XUL                         0x0021760b nsXREDirProvider::DoShutdown() + 291 (nsXREDirProvider.cpp:836)
#
17  XUL                         0x00207b20 ScopedXPCOMStartup::~ScopedXPCOMStartup [in-charge]() + 124 (nsAppRunner.cpp:896)
#
18  XUL                         0x0020f26e XRE_main + 7312 (nsAppRunner.cpp:3248)
#
19  org.mozilla.firefox         0x00002798 main + 708 (nsBrowserApp.cpp:158)
#
20  org.mozilla.firefox         0x00001dca _start + 216
#
21  org.mozilla.firefox         0x00001cf1 start + 41
#
 
#
Thread 1:
#
0   libSystem.B.dylib           0x9001a1cc select + 12
#
1   libnspr4.dylib              0x005cf6c8 _pr_poll_with_poll + 1333 (ptio.c:3899)
#
2   libnspr4.dylib              0x005cf936 PR_Poll + 31 (ptio.c:4303)
#
3   libnecko.dylib              0x13d9224d nsSocketTransportService::Poll(int, unsigned*) + 223 (nsSocketTransportService2.cpp:346)
#
4   libnecko.dylib              0x13d936a1 nsSocketTransportService::DoPollIteration(int) + 803 (nsSocketTransportService2.cpp:641)
#
5   libnecko.dylib              0x13d939af nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal*, int, unsigned) + 61 (nsSocketTransportService2.cpp:519)
#
6   libxpcom_core.dylib         0x016fbcfd nsThread::ProcessNextEvent(int, int*) + 415 (nsThread.cpp:500)
#
7   libxpcom_core.dylib         0x016a12a5 NS_ProcessNextEvent_P(nsIThread*, int) + 129 (nsThreadUtils.cpp:227)
#
8   libnecko.dylib              0x13d931f7 nsSocketTransportService::Run() + 293 (nsSocketTransportService2.cpp:550)
#
9   libxpcom_core.dylib         0x016fbe01 nsThread::ProcessNextEvent(int, int*) + 675 (nsThread.cpp:511)
#
10  libxpcom_core.dylib         0x016a12a5 NS_ProcessNextEvent_P(nsIThread*, int) + 129 (nsThreadUtils.cpp:227)
#
11  libxpcom_core.dylib         0x016fc00e nsThread::ThreadFunc(void*) + 262 (nsThread.cpp:253)
#
12  libnspr4.dylib              0x005d0eb7 _pt_root + 313 (ptthread.c:224)
#
13  libSystem.B.dylib           0x90024227 _pthread_body + 84
#

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

The stack looks similar to https://bugzilla.mozilla.org/show_bug.cgi?id=408601#c6
Kai, any help here would be great.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #0)
> This crash was also reported in Bug 408601
Um, didn't notice this.

Comment 3

[Jesse Ruderman]

WFM, Mac trunk debug.

Is an assertion message printed on the console before the crash?

Comment 4

[Kai Engert [:KaiE:]]

Bug 411743, Bug 408601 and bug 412338 all crash with a stack that goes back to nsPSMBackgroundThread::requestExit(), but we crash at different places.

This smells like memory corruption.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Note also the assertions 
###!!! ASSERTION: nsStreamLoader not thread-safe: '_mOwningThread.GetThread()
== PR_GetCurrentThread()', file
/home/smaug/mozilla/mozilla_cvs/mozilla/netwerk/base/src/nsStreamLoader.cpp,
line 65

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So the original patch that triggered this seems to have been Bug 158066. The patch there put back in some code that graydon originally was crashing when he used. See

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.899&mark=679-684,735,736#672

I really think we want to keep the patch from bug 158066 since without it content pages can trivially leak. So I think we really need to figure out why this is crashing. And preferably soon since this crash seems easy to trigger.

Comment 7

[Johnathan Nightingale [:johnath]]

Current Mac trunk, non-debug build, this doesn't crash for me.  I know Kai recently updated the version of NSS we pull (bug 399590) - Tomcat - do you still see it?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

With current debug-linux-build the behavior is strange. FF doesn't crash
but when loading the certificate looks like something is crashing.
Does some part of nss run in a separate process or something?
Will debug this some more.

UNKNOWN [/lib64/libpthread.so.0 +0x0000DE00]
gsignal+0x00000035 [/lib64/libc.so.6 +0x000305C5]
abort+0x00000110 [/lib64/libc.so.6 +0x00032070]
UNKNOWN [./libmozjs.so +0x0009A65F]
JS_BeginRequest+0x00000036 [./libmozjs.so +0x00020CE0]
UNKNOWN [/home/smaug/mozilla/mozilla_cvs/mozilla/ff_build/dist/bin/components/libxpconnect.so +0x0001F7DE]
UNKNOWN [/home/smaug/mozilla/mozilla_cvs/mozilla/ff_build/dist/bin/components/libxpconnect.so +0x000442D0]
nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&)+0x0000001F [./libxpcom_core.so +0x0003C3C5]
UNKNOWN [./libxpcom_core.so +0x0008AE5D]
NS_GetProxyForObject(nsIEventTarget*, nsID const&, nsISupports*, int, void**)+0x00000080 [./libxpcom_core.so +0x0008A87A]
UNKNOWN [/home/smaug/mozilla/mozilla_cvs/mozilla/ff_build/dist/bin/components/libpipnss.so +0x0003931A]
UNKNOWN [./libssl3.so +0x0001872B]
UNKNOWN [./libssl3.so +0x00019F83]
UNKNOWN [./libssl3.so +0x0001A36C]
UNKNOWN [./libssl3.so +0x0001AE14]
UNKNOWN [./libssl3.so +0x0001BEF6]
UNKNOWN [./libssl3.so +0x0001EA4B]
UNKNOWN [./libssl3.so +0x00026F53]
UNKNOWN [./libssl3.so +0x000290C1]
UNKNOWN [./libssl3.so +0x0002925C]
UNKNOWN [./libssl3.so +0x0002F66E]
UNKNOWN [/home/smaug/mozilla/mozilla_cvs/mozilla/ff_build/dist/bin/components/libpipnss.so +0x00022C3A]
UNKNOWN [./libnspr4.so +0x0002C1A5]
UNKNOWN [/lib64/libpthread.so.0 +0x000062F7]

Comment 9

[Jeff Walden [:Waldo]]

(In reply to comment #8)

fix-linux-stack.pl doesn't give more useful information when run on this?

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: crash stack

This is the stack I get when the weird crash happens. FF continues to run after
that, though trying to load for example any https sites fails.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

The assertion was missing in the stack
Assertion failure: cx->thread->id == js_CurrentThreadId(), at /home/smaug/mozilla/mozilla_cvs/mozilla/js/src/jsapi.c:852

Comment 12

[Carsten Book [:Tomcat]]

works for me in windows (no crash and no such assertion), will generate a mac debug build now

Comment 13

[Carsten Book [:Tomcat]]

(In reply to comment #11)
> The assertion was missing in the stack
> Assertion failure: cx->thread->id == js_CurrentThreadId(), at
> /home/smaug/mozilla/mozilla_cvs/mozilla/js/src/jsapi.c:852
> 

confirmed, my mac debug build crashed too and i see assertion failure: cx->thread->id == js_CurrentThreadId(), at /debug/mozilla/js/src/jsapi.c:852

Comment 14

[Caio Tiago Oliveira (asrail)]

Changing OS... linux + max os = all.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Kai, any updates here? This bug looks really bad so it'd be great to have it fixed for beta3 which freezes in less then a week.

Comment 16

[Mike Schroepfer]

Kai - any updates here?

Comment 17

[Kai Engert [:KaiE:]]

Hopefully this is a duplicate of bug 414745.
The assertion mentioned in comment 13 looks similar.

We should test this once Firefox uses a new NSPR tag with the fix from bug 414997.

This bug is reported as Mac+Linux, which is consistent with the findings in bug 414745 comment 3.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Tomcat, can you reproduce this now that 414997 is fixed?

Comment 19

[Carsten Book [:Tomcat]]

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

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

fixed also on Linux.
The following assertion I get is something else:
###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/smaug/mozilla/mozilla_cvs/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp, line 169

Comment 21

[Carsten Book [:Tomcat]]

verified fixed per comment #19 and comment #20

-> Verified fixed