304430 - Crashed when closing Firefox [@ JS_GetClass - GetScopeOfObject][@ 0x20202020 - JS_GetClass][@ 0x00000001 - JS_GetClass][@ 0x01010101 - JS_GetClass][@ 0xc8900960 - JS_GetClass][@ 0x40096c71 - JS_GetClass][@ 0x01012020 - JS_GetClass][@ GetScopeOfObject]

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Caleb]

I just got this crash when I closed Firefox with GMail open.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050812
Firefox/1.0+ ID:2005081201

With browser.sessionhistory.max_viewers = 5.

Talkback ID: TB8309425E
--------------------------------------

JS_GetClass 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 2105]
XPCWrappedNativeScope::FindInJSObjectScope 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp,
line 594]
nsXPConnect::WrapNative 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/nsXPConnect.cpp,
line 582]
nsDOMMouseEvent::QueryInterface 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsDOMMouseEvent.cpp,
line 85]
nsEventListenerManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 2018]
nsEventListenerManager::GetCoordinatesFor 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 2175]
nsGlobalWindow::SetScriptsEnabled 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 1313]
DocumentViewerImpl::SetBounds 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 1685]
SameOrSubdomainOfTarget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 958]
SameOrSubdomainOfTarget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 971]
SameOrSubdomainOfTarget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 971]
nsDocShell::GetVisibility 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 3609]
nsXULWindow::SetVisibility 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 781]
nsASXULWindowEnumerator::`scalar deleting destructor'
nsWebShellWindow::ExecuteCloseHandler 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 809]
nsWindow::DispatchStandardEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1278]
nsWindow::DispatchAppCommandEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1298]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 4804]
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1466]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0xb4c0 (0x77d4b4c0)
USER32.dll + 0xb50c (0x77d4b50c)
ntdll.dll + 0xeae3 (0x7c90eae3)
USER32.dll + 0xb3f9 (0x77d4b3f9)
uxtheme.dll + 0x3c20 (0x5ad73c20)
uxtheme.dll + 0x1e300 (0x5ad8e300)
uxtheme.dll + 0x1ac7 (0x5ad71ac7)
uxtheme.dll + 0x1b3d (0x5ad71b3d)
USER32.dll + 0xbb15 (0x77d4bb15)
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1488]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0xc63f (0x77d4c63f)
USER32.dll + 0xc665 (0x77d4c665)
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1471]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0xb4c0 (0x77d4b4c0)
USER32.dll + 0xb50c (0x77d4b50c)
ntdll.dll + 0xeae3 (0x7c90eae3)
USER32.dll + 0xb903 (0x77d4b903)
uxtheme.dll + 0x2881f (0x5ad9881f)
uxtheme.dll + 0x1ac7 (0x5ad71ac7)
uxtheme.dll + 0x1b3d (0x5ad71b3d)
USER32.dll + 0xbb15 (0x77d4bb15)
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1488]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0xc63f (0x77d4c63f)
USER32.dll + 0xc665 (0x77d4c665)
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1471]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::GetNativeEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 189]
nsAppStartup::Observe 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 495]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 1

[Caleb]

I'm not sure what's causing this, but I've never crashed like this before, and
this is a pretty fresh build (after jst's splitwindows update patch).

Comment 2

[timeless]

*** Bug 304937 has been marked as a duplicate of this bug. ***

Comment 3

[Jo Hermans]

*** Bug 305490 has been marked as a duplicate of this bug. ***

Comment 4

[Jo Hermans]

This is spot #15 in the hitlist today. It looks like bug 295101, but that was
supposed to have been fixed in May.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is this at all reproducible?

Comment 6

[Peter Weilbacher]

Not for me, at least not any more. I tried various ways to get it to crash again
like it did 10 days ago this but it doesn't happen any more. 

Comment 7

[dolphinling]

bz: not reproducible in any useful way, but I'm still getting it more than
enough to be annoying. (Note that I'm not crashing when closing Firefox, but
when I click a link. (My bug was duped here, though, and was also @ JS_GetClass.))

I've been sending in tons of talkbacks (stopped counting at 10) but if there's
any way I can give more information, I'd be glad to. 

Comment 8

[Boris Zbarsky [:bzbarsky]]

dolphinling, what's a talkback incident ID for your crash?  Does it happen with
a clean profile?  If not, can you track it to a particular extension?

Comment 9

[Caleb]

I'd like to make a note, I was getting lots of crashes about 2 weeks ago, and
this was one of them.

It seems like my motherboard went haywire and caused some memory corruption
leading up to all kinds of interesting stacks/crashes.

I can't explain the bugs duped against this one, but I'd like to warn you not to
rely on the posted stack too much.

Comment 10

[timeless]

based on these other crashes, the object was gc'd

Comment 11

[dolphinling]

bz: It does crash with a clean profile. The most recent talkbacks of mine are
TB9038840, TB9067382, TB9067622, TB9067712, TB9084281, and (with a clean
profile) TB9087098. 

Comment 12

[Jesse Ruderman]

This is at least the #4 topcrash on Windows for branch builds, where it appears
most often with stack signature "xpsp2res.dll".  It also seems like it could be
an exploitable security hole, since the instruction pointer ends up at a
random-seeming address.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmm... Is this crashing on branch but _not_ on trunk?  If so, perhaps it's a
matter of some patches not having made it to branch?  That said, I can't seem to
reproduce on trunk _or_ branch with Linux builds...

That said, it looks like nsJSEventListener just holds a JSObject* to its scope
and that this scope is what's getting GCed out from under it here (because it's
the inner window, probably; I see nothing that would keep one alive here). 
Perhaps nsJSEventListener should root the scope?

Comment 14

[timeless]

xpsp2res happens to like to live near 0x20000000 which is near the gc marker 
0x20202020, i'm not so sure someone could usefully exploit the garbage 
collector on that vector. the dead object case (0xc8900960 and 0x40096c71) 
worries me more.

Comment 15

[Johnny Stenback (:jst)]

Attachment: Probable fix, lock nsJSEventListener::mScopeObject to prevent it from being GC:d

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 195150 [details] [diff] [review]
Probable fix, lock nsJSEventListener::mScopeObject to prevent it from being GC:d

Hmm... I hope this was leak-tested, since this now means the JS event listener
holds refs to both the inner and the outer window...

I almost wonder whether it would make more sense to register listeners with the
inner window so they get notified if it goes away...

Comment 17

[Brendan Eich [:brendan]]

Comment on attachment 195150 [details] [diff] [review]
Probable fix, lock nsJSEventListener::mScopeObject to prevent it from being GC:d

Man, it was six or seven years ago when I pressed joki about why these weak
refs were safe.  IIRC the idea was that strong refs in the JS DOM kept the
handler and its parent (the scope object, i presume) alive.  If someone used
the delete operator to cut a property link, then bad things could happen, but
that bug never was fixed.

Some comments say that we guarantee LIFO allocation, or something:
http://lxr.mozilla.org/mozilla/source/dom/public/nsIJSEventListener.h#63 --
it's not clear to me how this works.

Should this gc-thing locking happen here or in nsIJSEventListener, the
deCOMtaminated no-longer-abstract base class?  Why do we have that still,
anyway?

/be

Comment 18

[dolphinling]

This has over 450 talkback reports sent in under various guises--easily enough
to put it at the top of the topcrash list. Adding topcrash keyword.

Also adding regression keword, 'cause it is.

Between those two, I certainly hope we get this for 1.8b5...

Comment 19

[Scott MacGregor]

plussing. This looks like a stopper bug to me.

Comment 20

[Uri Bernstein]

I got a similar (I think) crash on OS X: TB9338559.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050913
Firefox/1.4

Not sure what I was doing when it happened, but certainly not closing the browser.

Stack trace form the Apple reporter:

Date/Time:      2005-09-14 14:41:15.046 +0300
OS Version:     10.4.2 (Build 8C46)
Report Version: 3

Command: firefox-bin
Path:    /Users/urib/Desktop/Firefox 1.4 2005-09-13.app/Contents/MacOS/firefox-bin
Parent:  launchd [1]

Version: 1.4 (1.4)

PID:    20957
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x20202020

Thread 0 Crashed:
0   <<00000000>> 	0x20202020 0 + 538976288
1   org.mozilla.firefox 	0x00091c38
XPCWrappedNativeScope::SystemIsBeingShutDown(XPCCallContext&) + 232
2   org.mozilla.firefox 	0x00091d04
XPCWrappedNativeScope::FindInJSObjectScope(XPCCallContext&, JSObject*, int) + 40
3   org.mozilla.firefox 	0x0044428c
XPCConvert::NativeInterface2JSObject(XPCCallContext&,
nsIXPConnectJSObjectHolder**, nsISupports*, nsID const*, JSObject*, int,
unsigned*) + 96
4   org.mozilla.firefox 	0x00086620 nsXPConnect::WrapNative(JSContext*,
JSObject*, nsISupports*, nsID const&, nsIXPConnectJSObjectHolder**) + 148
5   org.mozilla.firefox 	0x001cb260
nsEventListenerManager::CompileEventHandlerInternal(nsIScriptContext*,
JSObject*, nsISupports*, nsIAtom*, nsListenerStruct*, nsIDOMEventTarget*,
unsigned) + 148
6   org.mozilla.firefox 	0x001cb844
nsEventListenerManager::HandleEventSubType(nsListenerStruct*, nsIDOMEvent*,
nsIDOMEventTarget*, unsigned, unsigned) + 428
7   org.mozilla.firefox 	0x001cbc0c
nsEventListenerManager::HandleEvent(nsPresContext*, nsEvent*, nsIDOMEvent**,
nsIDOMEventTarget*, unsigned, nsEventStatus*) + 736
8   org.mozilla.firefox 	0x00246a9c
nsGenericElement::HandleDOMEvent(nsPresContext*, nsEvent*, nsIDOMEvent**,
unsigned, nsEventStatus*) + 1440
9   org.mozilla.firefox 	0x002626bc
nsGenericHTMLElement::HandleDOMEventForAnchors(nsPresContext*, nsEvent*,
nsIDOMEvent**, unsigned, nsEventStatus*) + 56
10  org.mozilla.firefox 	0x005001f8
nsEventStateManager::DispatchMouseEvent(nsGUIEvent*, unsigned, nsIContent*,
nsIContent*) + 320
11  org.mozilla.firefox 	0x00500558
nsEventStateManager::NotifyMouseOver(nsGUIEvent*, nsIContent*) + 308
12  org.mozilla.firefox 	0x00500658
nsEventStateManager::GenerateMouseEnterExit(nsGUIEvent*) + 200
13  org.mozilla.firefox 	0x004fbf84
nsEventStateManager::PreHandleEvent(nsPresContext*, nsEvent*, nsIFrame*,
nsEventStatus*, nsIView*) + 764
14  org.mozilla.firefox 	0x0014f1d0 PresShell::HandleEventInternal(nsEvent*,
nsIView*, unsigned, nsEventStatus*) + 616
15  org.mozilla.firefox 	0x0014ee54 PresShell::HandleEvent(nsIView*,
nsGUIEvent*, nsEventStatus*, int, int&) + 1304
16  org.mozilla.firefox 	0x0020b300 nsViewManager::HandleEvent(nsView*,
nsGUIEvent*, int) + 792
17  org.mozilla.firefox 	0x0020a4c4 nsViewManager::DispatchEvent(nsGUIEvent*,
nsEventStatus*) + 3356
18  org.mozilla.firefox 	0x00506cc0 ViewWrapper::GetInterface(nsID const&,
void**) + 468
19  org.mozilla.firefox 	0x0069525c nsWindow::DispatchEvent(nsGUIEvent*,
nsEventStatus&) + 172
20  org.mozilla.firefox 	0x006952e8 nsWindow::DispatchWindowEvent(nsGUIEvent&) + 32
21  org.mozilla.firefox 	0x006953ac nsWindow::DispatchMouseEvent(nsMouseEvent&)
+ 112
22  org.mozilla.firefox 	0x0069198c
nsMacEventHandler::HandleMouseMoveEvent(EventRecord&) + 856
23  org.mozilla.firefox 	0x0068f94c
nsMacEventHandler::HandleOSEvent(EventRecord&) + 380
24  org.mozilla.firefox 	0x00302be8 nsMacWindow::DispatchEvent(void*, int*) + 56
25  org.mozilla.firefox 	0x0068bc20
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, OpaqueWindowPtr*) + 96
26  org.mozilla.firefox 	0x0068b9ac nsMacMessagePump::DoMouseMove(EventRecord&)
+ 152
27  org.mozilla.firefox 	0x0068af9c nsMacMessagePump::DispatchEvent(int,
EventRecord*) + 304
28  org.mozilla.firefox 	0x0068adb4 nsMacMessagePump::DoMessagePump() + 64
29  org.mozilla.firefox 	0x002fc61c nsAppShell::Run() + 56
30  org.mozilla.firefox 	0x0039b468 nsAppStartup::Run() + 40
31  org.mozilla.firefox 	0x000142d8 XRE_main + 3696
32  org.mozilla.firefox 	0x0000f6a8 start + 432
33  org.mozilla.firefox 	0x0000f528 start + 48 

Comment 21

[Brendan Eich [:brendan]]

Comment on attachment 195150 [details] [diff] [review]
Probable fix, lock nsJSEventListener::mScopeObject to prevent it from being GC:d

sr=me.	Looks good, too bad we can't optimize these GC-thing locks away when
there are named (necessarily strong) refs known to exist.

/be

Comment 22

[timeless]

*** Bug 308656 has been marked as a duplicate of this bug. ***

Comment 23

[dolphinling]

Hate to bug people, but can this be checked in? Is there anything other than
approval it needs?

Comment 24

[Johnny Stenback (:jst)]

Taking bug.

Comment 25

[Johnny Stenback (:jst)]

Fix landed on trunk and branch.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Dare I ask how this is supposed to not leak?

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(To put it a little more bluntly, listings on http://tv.yahoo.com/ leak because of this patch, and I don't see any reason this patch shouldn't cause leaks.)

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed the leak as bug 317478.