Closed Bug 411743 Opened 17 years ago Closed 16 years ago

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

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta4

People

(Reporter: cbook, Assigned: KaiE)

References

Details

(Keywords: crash, hang, regression)

Attachments

(2 files)

crash stack
32.38 KB, text/plain
Details
crash stack
3.58 KB, text/plain
Details
Attached file 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
#
Flags: blocking1.9?
The stack looks similar to https://bugzilla.mozilla.org/show_bug.cgi?id=408601#c6
Kai, any help here would be great.
(In reply to comment #0)
> This crash was also reported in Bug 408601
Um, didn't notice this.
WFM, Mac trunk debug.

Is an assertion message printed on the console before the crash?
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.
Depends on: 408601, 412338
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
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.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
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?
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]
(In reply to comment #8)

fix-linux-stack.pl doesn't give more useful information when run on this?
Attached file 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.
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
works for me in windows (no crash and no such assertion), will generate a mac debug build now
(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
Summary: Steps to reproduce from Bug 402749 crash Mac Debug Builds → Steps to reproduce from Bug 402749 crash Mac and Linux Debug Builds
Changing OS... linux + max os = all.
OS: Mac OS X → All
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.
Kai - any updates here?
Priority: P1 → P2
Priority: P2 → P1
Target Milestone: --- → mozilla1.9beta4
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.
Depends on: 414997
Tomcat, can you reproduce this now that 414997 is fixed?
confirmed fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008013112 Firefox/3.0b3pre
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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
verified fixed per comment #19 and comment #20

-> Verified fixed
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: