318969 - [FIX]crash [@ js_LinkFunctionObject b429c37f] jsfun.c line 2028

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051202 Firefox/1.5
Build Identifier: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051202 Firefox/1.5", build ID:2005120203

see Talkback event TB12533626K

Reproducible: Didn't try

Steps to Reproduce:

Actual Results:  
crash (access violation)

Expected Results:  
no crash

Not sure if "Core/JavaScript Engine" is where this bug belongs but I'm pretty sure "Firefox/General" is not.

Comment 1

[Tony Mechelynck [:tonymec]]

Guess: crashing on the same source line makes it a dupe. Or doesn't it?

*** This bug has been marked as a duplicate of 318633 ***

Comment 2

[timeless]

please don't judge gc crashes by their final frame, what matters is the journey.

In this case, i'd like to blame XPC_NW_NewResolve -- I'm not quite sure yet whicih piece of it is responsible for misplacing the function, but i'm hoping i'm right.

Incident ID: 12533626
Stack Signature	js_LinkFunctionObject b429c37f
Product ID	Firefox15
Build ID	2005120203
Trigger Time	2005-12-02 18:26:36.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0001c791)
URL visited	
User Comments	I had just hit Ctrl-Tab to go to the next tab
Since Last Crash	21295 sec
Total Uptime	21295 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 2028
Stack Trace 	
js_LinkFunctionObject  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 2028]
XPC_NW_NewResolve  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 847]
js_LookupPropertyWithFlags  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2675]
js_LookupProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2580]
js_GetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2865]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5249]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1197]
nsXPCWrappedJSClass::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1369]
nsXPCWrappedJS::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 462]
SharedStub  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1786]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2153]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleChromeEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2833]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1574]
nsDocument::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4013]
nsEventStateManager::DispatchNewEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 4554]
nsDocument::DispatchEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4097]
nsDocument::DispatchContentLoadedEvents  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 2213]
nsHTMLDocument::EndLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 983]
HTMLContentSink::DidBuildModel  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2203]
CNavDTD::DidBuildModel  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 604]

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> please don't judge gc crashes by their final frame, what matters is the
> journey.

Well, apparently I'm not qualified to make _any_ proper assessment on my crashes. When I try to find a preexisting instance of the same bug (and get it wrong, now what else is new?) I get a "please don't" from you, and when I don't, or when I try and don't succeed, I get a "please try" from Brendan. Well, can't please everyone I guess. Next time, I'll report my crash as a _new_ bug in category "Firefox/General" without troubling to search, and let Brendan and you (and any other guru that comes along) sort it out between yourselves. Sorry.

P.S. I'm not flaming anyone (except maybe myself) but I _really_ feel helpless. Almost as if I got a Firefox crash every time the zero comes out at a Las Vegas roulette (I live in Belgium, by the way).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Methinks timeless is right

Comment 5

[Boris Zbarsky [:bzbarsky]]

We should probably get that in on branch too.

Comment 6

[timeless]

tony: it's ok. it took me years to get to the point where i can recognize these crashes. and i read just about every crash reported in the entire bugzilla database. I also crash more than probably everyone else.

i still don't file bugs in spidermonkey as confirmed, and i've been able to grant canconfirm to others for more than five years.

the basics of spidermonkey crashes:
1. is it a null pointer dereference?
1Y. is the top frame supposed to handle null pointers?
1Y2Y. fix the top frame.
1Y2N. follow the call chain until you find a frame that is supposed to handle null pointers and passed it to a frame that doesn't want null pointers.
1N2. Is it a garbage collection crash?
1N2N. you'll want another tutorial. hopefully if you build debug you'll trip on a JS_Assert and that will help you find a bug if it's reported or file a useful bug.
1N2Y3. Is JS_GC or a relative in the stack trace?
1N2Y3Y. You're probably stuck.
1N2Y3N. Hopefully the object was very recently created and destroyed under the current stack trace.
1N2Y3N4. Is there a function that says New or Compile or that otherwise indicates that an object was being created in this stack?
1N2Y3N4Y. crawl the stack and find the frame that created the object. No frames past this point matter.
1N2Y3N4Y5. can you find a bugzilla bug which has that function listed in a crash stack and indications of a GC crash?
1N2Y3N4Y5Y. this bug should be your bug
1N2Y3N4Y5N. you can probably file a new bug. if you happen to miss it, that's life. please when you file it, try to file it based on the frame that called the allocator. in this bug, XPC_NW_NewResolve was the thing that did the creation, and it's from xpconnect, which makes core:xpconnect the proper place for the bug. in general, while you can file a bug in jsengine, it's probably not right (most of those bugs were rooted out this year, which isn't to say they're all gone, but hopefully i'll find them before you).

Comment 7

[Brendan Eich [:brendan]]

This needs to be fixed ASAP, I think.

/be

Comment 8

[Tony Mechelynck [:tonymec]]

(In reply to comment #6)
> tony: it's ok. it took me years to get to the point where i can recognize these
> crashes. and i read just about every crash reported in the entire bugzilla
> database. I also crash more than probably everyone else.
> 
> i still don't file bugs in spidermonkey as confirmed, and i've been able to
> grant canconfirm to others for more than five years.
> 
> the basics of spidermonkey crashes:
[...]

Timeless, you're making my head swim, I'm just not competent to do all you describe. 
<offtopic>
I have done high- and low-level language programming, and even mem-dump poring and sight disassembly, but that was 30 to 35 years ago on a mainframe occupying twice the whole size of my current apartment. It had a lot of core memory -- 128K -- and was quite fast -- 667 kHz. It had no CRT but a TTY35 console, tapes, disks, a card reader, and a 1200 lpm printer which knew only uppercase. 
</offtopic>
You're making me feel my years: I just can't follow anymore. Sorry. I feel like I would need a page of explanations about how to perform each one of your steps, and I feel like it's not worth trying. Fetching incidents back from the TB queue and doing a feeble first attempt at building a "proper" bug report out of them is the most I can reliably do.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 204992 [details] [diff] [review]
Methinks timeless is right

XPCNativeMember seems sort of scary (it seems that random GCs can cause its jsval member to go away). I hope most XPCNativeMembers are short lived! r=mrbkap

Comment 10

[Brendan Eich [:brendan]]

(In reply to comment #8)
> Fetching incidents back from the
> TB queue and doing a feeble first attempt at building a "proper" bug report out
> of them is the most I can reliably do.

Just do that then -- it helps, and don't let anyone make you feel unwelcome.  It is never wrong to file a bug if you see a problem and can't be sure it is already covered by an existing bug.  If you find existing bugs that look similar, please do cite them in the new bug.  Thanks,

/be

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 204992 [details] [diff] [review]
Methinks timeless is right

sr=jst

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 204992 [details] [diff] [review]
Methinks timeless is right

We should take this on branch -- it's a safe crash fix that just makes sure GC doesn't destroy our object out from under us.

Comment 15

[Tony Mechelynck [:tonymec]]

Is it really fixed? I got the following crash -- TB12921285Y -- on "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051213 Firefox/1.5", build ID:2005121303

Stack Signature	 js_LinkFunctionObject b429c37f
Product ID	Firefox15
Build ID	2005121303
Trigger Time	2005-12-13 12:40:30.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0001c791)
URL visited	
User Comments	restarting Firefox. It had been closed and was restarting.
Since Last Crash	15616 sec
Total Uptime	15616 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 2028
Stack Trace 	
js_LinkFunctionObject  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsfun.c, line 2028]
XPC_NW_NewResolve  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 847]
js_LookupPropertyWithFlags  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2675]
js_LookupProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2580]
js_GetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2865]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5249]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1197]
nsXPCWrappedJSClass::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1369]
nsXPCWrappedJS::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 462]
SharedStub  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1786]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2153]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleChromeEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2833]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1574]
nsDocument::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4013]
nsEventStateManager::DispatchNewEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 4554]
nsDocument::DispatchEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4097]
nsDocument::DispatchContentLoadedEvents  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 2213]
nsHTMLDocument::EndLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 983]
HTMLContentSink::DidBuildModel  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2203]
CNavDTD::DidBuildModel  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 604]

Comment 16

[timeless]

it's really not fixed in 1.8, hence the approval 1.8.0.1 request

Comment 17

[Mike Schroepfer]

Comment on attachment 204992 [details] [diff] [review]
Methinks timeless is right

Please land on both 1.8.0 and 1.8 branches.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Could someone please land this for me?  If not, I'll do it in early January...

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Checked in on both branches.
1.8:
mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp; new revision: 1.31.2.5;
1.8.0:
mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp; new revision: 1.31.2.4.2.1;

Comment 20

[Jay Patel [:jay]]

v.fixed on trunk and both branches based on latest Talkback data.

Comment 21

[Wayne Mery (:wsmwk)]

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