stack overflow [@ nsThread::Shutdown] should protect against proxying for itself repeatedly

RESOLVED INCOMPLETE

Status

()

Core
XPCOM
--
critical
RESOLVED INCOMPLETE
9 years ago
6 years ago

People

(Reporter: Marc Horowitz, Unassigned)

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091230 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091230 Minefield/3.7a1pre

Before I upgraded from Ubuntu Jaunty (with firefox 3.0.x) to Karmic (firefox 3.5.x), I saved my current session of 34 windows and about 190 tabs. Firefox 3.5 is unable to restore this session; it crashes every time.* After churning for a minute or two, it seg faults.

I looked at the stack traces from several dumps. Each stack trace is different, but they all have a common characteristic: over 2000 frames of stack in the thread which seg faults.

I followed the directions at
https://developer.mozilla.org/En/Simple_Firefox_build#Building_Firefox
to do a debug build, and replicated the problem.  The stack trace contains about 2500 lines of this:

#2520 0x416a114e in nsThread::Shutdown (this=0x524e9d80) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/threads/nsThread.cpp:468
#2521 0x416bc005 in NS_InvokeByIndex_P () at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:69
#2522 0x416aab01 in nsProxyObjectCallInfo::Run (this=0x4896d130) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/proxy/src/nsProxyEvent.cpp:181
#2523 0x416a150c in nsThread::ProcessNextEvent (this=0x433d6290, mayWait=1, result=0xbfb51ab0) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/threads/nsThread.cpp:527
#2524 0x4163752d in NS_ProcessNextEvent_P (thread=0x433d6290, mayWait=1) at nsThreadUtils.cpp:250
#2525 0x416a114e in nsThread::Shutdown (this=0x524e96f0) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/threads/nsThread.cpp:468
#2526 0x416bc005 in NS_InvokeByIndex_P () at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:69
#2527 0x416aab01 in nsProxyObjectCallInfo::Run (this=0x4458eca0) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/proxy/src/nsProxyEvent.cpp:181
#2528 0x416a150c in nsThread::ProcessNextEvent (this=0x433d6290, mayWait=1, result=0xbfb51c20) at /u1/home/marc/sandbox/firefox/mozilla-central/xpcom/threads/nsThread.cpp:527
#2529 0x4163752d in NS_ProcessNextEvent_P (thread=0x433d6290, mayWait=1) at nsThreadUtils.cpp:250

On the ubuntu version, I looked at $pc in frame 0 and in the topmost frame, and they differed by about 200k. I didn't check the debug build, but I doubt it's much different.  Since I'm not running into the glibc stack limit, I can't be sure the deep stack is the cause of the core dump, but it's awfully suspicious, and the only remotely common thing about the multiple crashes I looked at.

I can't tell if something's just broken, or if there's some awful recursion which manages to complete in simpler cases but is failing catastrophically when there's an enormous amount of work to do.

When I start firefox again, it offers to restart the "previous" crashed session, which usually has between 12 and 24 tabs in it. If I restore a smaller session, firefox seems ok with it.

While I normally have a number of firefox add-ons enabled, the problem occurs if I enable only tab mix plus, which is necessary to restore the session it has stored.

Note: those paying close attention will notice this is the same issue as in https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/501562 which I also filed, but before building a debug version to generate the above report.

----
* Ok, sometimes it just freezes. I seem to have forgotten to save the core, but in that case, free() caused a seg fault, which caused something in the signal handler to try to call free(), which deadlocked on a mutex. Oops. If it happens again I'll file a new bug with that stack trace.

Reproducible: Always

Steps to Reproduce:
1. Start firefox with tab mix plus loaded
2. Restore from a 34 frame 190 tab session (hopefully any, because mine has private data in it)
3. Wait.
Actual Results:  
firefox core dumps.

Expected Results:  
all my tabs are loaded
(Reporter)

Comment 1

9 years ago
Created attachment 419679 [details]
stack trace of all threads at core dump (note thread 1)
(Reporter)

Updated

9 years ago
Attachment #419679 - Attachment mime type: application/octet-stream → text/plain
Status: UNCONFIRMED → NEW
Component: General → Session Restore
Ever confirmed: true
QA Contact: general → session.restore

Updated

9 years ago
Component: Session Restore → XPCOM
Keywords: crash
Product: Firefox → Core
QA Contact: session.restore → xpcom
Summary: firefox crashes on tab mix plus session restore with 2500+ frame stack → stack overflow [@ nsThread::Shutdown] should protect against proxying for itself repeatedly
Version: unspecified → Trunk

Comment 2

7 years ago
Marc?

Marc seems to be gone, so I'm not sure if his crash is gone.

There are crashes for nsThread::Shutdown() such as
bp-58c21320-ef0f-4bc3-8dfc-53baf2110402
EXCEPTION_ACCESS_VIOLATION_EXEC
0x9315c0
0		@0x9315c0	
1	xul.dll	nsThread::Shutdown	xpcom/threads/nsThread.cpp:484
2	xul.dll	nsSocketTransportService::Shutdown	netwerk/base/src/nsSocketTransportService2.cpp:470
3	xul.dll	nsIOService::SetOffline	netwerk/base/src/nsIOService.cpp:745
4	xul.dll	nsIOService::Observe	netwerk/base/src/nsIOService.cpp:933
5	xul.dll	nsObserverList::NotifyObservers	xpcom/ds/nsObserverList.cpp:130
6	xul.dll	nsObserverService::NotifyObservers	xpcom/ds/nsObserverService.cpp:182
Whiteboard: [closeme 2011-06-01]
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsThread::Shutdown]

Comment 3

6 years ago
Resolved per whiteboard
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2011-06-01]
You need to log in before you can comment on or make changes to this bug.