368916 - crash SEGV on shutdown [@ 0x00000021] [@ JS_GetClass()]

Status: RESOLVED DUPLICATE of bug 369717

(Core :: DOM: Core & HTML, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070130 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070130 SeaMonkey/1.5a

TB28900567E


Reproducible: Didn't try

Actual Results:  
crash

Expected Results:  
no crash

Incident ID: 28900567
Stack Signature	0x00000021 04b79cf8
Product ID	MozillaTrunk
Build ID	2007013003
Trigger Time	2007-01-31 15:56:56.0
Platform	LinuxIntel
Operating System	Linux 2.6.11.4-21.15-default
Module	
URL visited	
User Comments	closing down SeaMonkey
Since Last Crash	11 sec
Total Uptime	11 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
0x00000021
JS_GetClass()  [mozilla/js/src/jsapi.c, line 2272]
JS_ClearScope()  [mozilla/js/src/jsapi.c, line 3225]
nsJSContext::ClearScope()  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 2983]
nsGlobalWindow::FreeInnerObjects()  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 631]
nsGlobalWindow::SetDocShell()  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1689]
nsDocShell::Destroy()  [mozilla/docshell/base/nsDocShell.cpp, line 909]
nsFrameLoader::Destroy()  [mozilla/content/base/src/nsFrameLoader.cpp, line 713]
nsGenericHTMLFrameElement::UnbindFromTree()  [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 713]
nsGenericElement::UnbindFromTree()  [mozilla/content/base/src/nsGenericElement.cpp, line 1845]
nsGenericElement::UnbindFromTree()  [mozilla/content/base/src/nsGenericElement.cpp, line 1845]
nsHTMLBodyElement::UnbindFromTree()  [mozilla/content/html/content/src/nsHTMLBodyElement.cpp, line 426]
nsGenericElement::UnbindFromTree()  [mozilla/content/base/src/nsGenericElement.cpp, line 1845]
nsDocument::Destroy()  [mozilla/content/base/src/nsDocument.cpp, line 5284]
DocumentViewerImpl::Destroy()  [mozilla/layout/base/nsDocumentViewer.cpp, line 713]
nsSHEntry::~nsSHEntry()  [mozilla/docshell/shistory/src/nsSHEntry.cpp, line 74]
nsSHEntry::Release()  [mozilla/docshell/shistory/src/nsSHEntry.cpp, line 128]
nsCOMPtr_base::~nsCOMPtr_base()  [mozilla/xpcom/build/nsCOMPtr.cpp, line 81]
nsDocShell::~nsDocShell()  [mozilla/docshell/base/nsDocShell.cpp, line 298]
nsWebShell::~nsWebShell()  [mozilla/docshell/base/nsWebShell.cpp, line 75]
nsDocLoader::Release()  [mozilla/uriloader/base/nsDocLoader.cpp, line 223]
nsDocShell::Release()  [mozilla/docshell/base/nsDocShell.cpp, line 395]
nsWebShell::Release()  [mozilla/docshell/base/nsWebShell.cpp, line 614]
XPCJSRuntime::GCCallback()  [mozilla/js/src/xpconnect/src/xpcjsruntime.cpp, line 590]
DOMGCCallback()  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 3257]
js_GC()  [mozilla/js/src/jsgc.c, line 3219]
JS_GC()  [mozilla/js/src/jsapi.c, line 1891]
nsProfile::ShutDownCurrentProfile()  [mozilla/profile/src/nsProfile.cpp, line 1354]
DoOnShutdown()  [mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 736]
main()  [mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1733]
libc.so.6 + 0x14e80 (0x40894e80)

Comment 1

[timeless]

hrm, how many copies of this crash did you file? i hit this in my build from around the end of the first week of feb.

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> hrm, how many copies of this crash did you file? i hit this in my build from
> around the end of the first week of feb.
> 

I think you got them all (but my memory is hazy). It isn't always easy to decide that "my crash" is "the same" as some already reported crash, especially when the top-of-stack address is bogus: Unless the search finds an obviously "almost identical" stack, I file a distinct bug "just in case it had a different cause". Is that OK? I realise it may be making more work for you.

Begin February I had to stop upgrading my trunk builds for several days, because Sm-trunk builds later than 20070131 would neither install nor run on SuSE 9 (libstdc++.so.6 not found). This explains why a crash I got on Feb. 8 (not this one, but another one with a different bogus top-of stack) was using a "Jan. 31" build. You added a "dependency" to it a few minutes ago, to a bug which was "fixed" on trunk & 1.8 branch around Feb. 6.