The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
XPConnect
--
critical
VERIFIED FIXED
12 years ago
6 years ago

People

(Reporter: tonymec, Assigned: bz)

Tracking

({crash, verified1.8.0.1, verified1.8.1})

Trunk
mozilla1.9alpha1
x86
Windows XP
crash, verified1.8.0.1, verified1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.1 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

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.
Keywords: crash
Version: Trunk → 1.8 Branch
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Comment 2

12 years ago
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]
Component: JavaScript Engine → XPConnect

Updated

12 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(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).
Created attachment 204992 [details] [diff] [review]
Methinks timeless is right
Attachment #204992 - Flags: superreview?(jst)
Attachment #204992 - Flags: review?(mrbkap)
We should probably get that in on branch too.
Assignee: general → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Summary: crash [@ js_LinkFunctionObject b429c37f] jsfun.c line 2028 → [FIX]crash [@ js_LinkFunctionObject b429c37f] jsfun.c line 2028

Comment 6

12 years ago
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).
This needs to be fixed ASAP, I think.

/be
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
(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 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
Attachment #204992 - Flags: review?(mrbkap) → review+
(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
*** Bug 318627 has been marked as a duplicate of this bug. ***
Comment on attachment 204992 [details] [diff] [review]
Methinks timeless is right

sr=jst
Attachment #204992 - Flags: superreview?(jst) → superreview+
Fixed.
Status: NEW → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Version: 1.8 Branch → Trunk
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.
Attachment #204992 - Flags: approval1.8.0.1?
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

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

Comment 17

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

Please land on both 1.8.0 and 1.8 branches.
Attachment #204992 - Flags: approval1.8.1+
Attachment #204992 - Flags: approval1.8.0.1?
Attachment #204992 - Flags: approval1.8.0.1+
Could someone please land this for me?  If not, I'll do it in early January...
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;
Keywords: fixed1.8.0.1, fixed1.8.1

Comment 20

11 years ago
v.fixed on trunk and both branches based on latest Talkback data.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.1, fixed1.8.1 → verified1.8.0.1, verified1.8.1
Keywords: fixed1.8.0.1

Updated

11 years ago
Keywords: fixed1.8.0.1
*** Bug 318633 has been marked as a duplicate of this bug. ***
Crash Signature: [@ js_LinkFunctionObject b429c37f]
You need to log in before you can comment on or make changes to this bug.