Closed Bug 785983 Opened 7 years ago Closed 3 years ago

crash in NameResolver::resolve


(Core :: JavaScript Engine, defect, critical)

17 Branch
Windows 7
Not set



Tracking Status
firefox16 --- unaffected
firefox17 --- affected
firefox18 --- affected
firefox19 --- affected
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 --- affected
firefox25 --- affected


(Reporter: scoobidiver, Assigned: jorendorff)



(Keywords: crash, regression, Whiteboard: [js:p2])

Crash Data

It first appeared in 17.0a1/20120824. The regression range is:
It's likely a regression from bug 433529.

Signature 	NameResolver::resolve(js::frontend::ParseNode*, JSAtom*) More Reports Search
UUID	a8b86b98-6920-42f7-b55d-e2fed2120827
Date Processed	2012-08-27 16:51:38
Uptime	602
Last Crash	2.0 hours before submission
Install Age	2.0 hours since version was first installed.
Install Time	2012-08-27 14:50:49
Product	Firefox
Version	17.0a1
Build ID	20120827030549
Release Channel	nightly
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
Build Architecture	x86
Build Architecture Info	GenuineIntel family 15 model 6 stepping 5
Crash Address	0x4
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x07e5, AdapterSubsysID: 07e51849, AdapterDriverVersion:
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x07e5
Total Virtual Memory	2147352576
Available Virtual Memory	1845411840
System Memory Use Percentage	65
Available Page File	1882898432
Available Physical Memory	327069696

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	NameResolver::resolve 	js/src/frontend/NameFunctions.cpp:261
1 	mozjs.dll 	NameResolver::resolve 	js/src/frontend/NameFunctions.cpp:280
10 	mozjs.dll 	NameResolver::resolve 	js/src/frontend/NameFunctions.cpp:283
11 	mozjs.dll 	js::frontend::CompileScript 	js/src/frontend/BytecodeCompiler.cpp:195
12 	mozjs.dll 	JS::Evaluate 	js/src/jsapi.cpp:5659
13 	mozjs.dll 	JS_EvaluateUCScriptForPrincipalsVersionOrigin 	js/src/jsapi.cpp:5746
14 	xul.dll 	nsJSContext::EvaluateString 	dom/base/nsJSEnvironment.cpp:1497
15 	xul.dll 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:841
16 	xul.dll 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:734
17 	xul.dll 	nsScriptLoader::ProcessPendingRequests 	content/base/src/nsScriptLoader.cpp:890
18 	xul.dll 	nsScriptLoader::OnStreamComplete 	content/base/src/nsScriptLoader.cpp:1109
19 	xul.dll 	nsStreamLoader::OnStopRequest 	netwerk/base/src/nsStreamLoader.cpp:95
20 	xul.dll 	nsMultipartProxyListener::OnStopRequest 	netwerk/streamconv/converters/nsHTTPCompressConv.cpp:94
21 	xul.dll 	nsStreamListenerTee::OnStopRequest 	netwerk/base/src/nsStreamListenerTee.cpp:49
22 	xul.dll 	mozilla::net::nsHttpChannel::OnStopRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4971
23 	xul.dll 	nsInputStreamPump::OnStateStop 	netwerk/base/src/nsInputStreamPump.cpp:559
24 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:374
25 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:82
26 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
27 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:117
28 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
29 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
30 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
31 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
32 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:273
33 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3800
34 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3877
35 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3953

More reports at:*%2C+JSAtom*%29*%2C+JSAtom*%29
Is there a way to get contextual information like what script was being run or what site was visited?
Keywords: needURLs
Assignee: general → jorendorff
Whiteboard: [js:p1:fx18]
Whiteboard: [js:p1:fx18] → [js:p2]
The existing signature is #52 in FF 18.0.2 so changing its status to 'affected'.
The added new signature is #40 in FF 19b6, it looks like it's the same bug and
that NameResolver::resolve just changed its signature slightly.
Crash Signature: [@ NameResolver::resolve(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolveFun(js::frontend::ParseNode*, JSAtom*)] → [@ NameResolver::resolve(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolveFun(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolve(js::frontend::ParseNode*, JS::Handle<JSAtom*>) ] [@ NameResolver::resolveFun(js::frontend::ParseNode* …
Crash Signature: [@ NameResolver::resolve(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolveFun(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolve(js::frontend::ParseNode*, JS::Handle<JSAtom*>) ] [@ NameResolver::resolveFun(js::frontend::ParseNode* … → [@ NameResolver::resolve(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolveFun(js::frontend::ParseNode*, JSAtom*)] [@ NameResolver::resolve(js::frontend::ParseNode*, JS::Handle<JSAtom*>)] [@ NameResolver::resolveFun(js::frontend::ParseNode* J…
I'm not sure that bug 433529 is really at fault.

I spent some time looking at NameResolver.cpp in changeset 8af6a22827ec and the crash. One can tell from the line numbers what sort of JavaScript parse nodes each recursive invocation of NameResolver::resolve was operating on; the top four frames are (youngest first):

261 'cur' is invalid, thus crash

The PN_FUNC arity makes it extremely likely that the oldest frame here is looking at a 'function' node. But those can have four sorts of children, all of which are of PN_LIST arity, and many of which can have PN_NAME nodes as children, so we don't know much else.

However, the PN_NAME frame is recursing on cur->maybeExpr(). The youngest frame checked that cur != NULL, but then apparently crashed trying to get that node's kind or arity, suggesting that the pointer is some non-NULL, invalid pointer. If that's the case, then the PN_NAME parse node is corrupt: cur->maybeExpr() should be either NULL or a legitimate parse node. (For example, there is a very similar pattern of recursion in js/src/frontend/Parser.cpp's CompExprTransplanter::transplant.)

I'm building that changeset now, and will try visiting the sites listed in comment 2.
Looking through a bunch of the newer crashes with this signature, I see a variety of parse node types leading to the same crash on line 276, which is performing a kind/arity check that should be safe on any valid parse node; the 'cur' pointer must be bad. Those bad pointers are coming from various fields of different sorts of parent nodes, not from a particular kind of parent node. So it seems unlikely that NameResolver is simply failing to correctly process a particular kind of parse tree; it seems more likely that the parse tree is being corrupted before NameResolver sees it.

I don't see any stray stores in NameResolver itself, though, and it's consuming a parse tree that has just been generated; there's not a lot of opportunity for the corruption to occur. No JavaScript runs between parsing and calling NameFunctions, nor can any GC happen.

I think we need to be able to reproduce this before we can do much else.

I've visited all the sites listed in comment 1; none of them had any difficulties (other than being stale, since they're from August). Could we get a fresh list of URLs?
Keywords: needURLs
It still happens.
Crash Signature: , JS::Handle<JSAtom*>)] → , JS::Handle<JSAtom*>)] [@ NameResolver::resolve] [@ NameResolver::resolveFun]
Hi reporter,

Can you please provide any details about how to reproduce this crash? Are there any steps to reproduce, or it just crash randomly?

Also, is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build ( and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (

Flags: needinfo?(scoobidiver)
Marking this as Resolved: Incomplete due to the lack of response from the reporter.
If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Closed: 3 years ago
Flags: needinfo?(scoobidiver)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.