Closed Bug 785983 Opened 13 years ago Closed 9 years ago

crash in NameResolver::resolve

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
17 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox16 --- unaffected
firefox17 --- affected
firefox18 --- affected
firefox19 --- affected
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 --- affected
firefox25 --- affected

People

(Reporter: scoobidiver, Assigned: jorendorff)

References

Details

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

Crash Data

It first appeared in 17.0a1/20120824. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5650196a8c7d&tochange=1c0ac073dc65 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 Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x4 App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x07e5, AdapterSubsysID: 07e51849, AdapterDriverVersion: 6.14.11.8208 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/message_loop.cc:201 29 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 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: https://crash-stats.mozilla.com/report/list?signature=NameResolver%3A%3Aresolve%28js%3A%3Afrontend%3A%3AParseNode*%2C+JSAtom*%29 https://crash-stats.mozilla.com/report/list?signature=NameResolver%3A%3AresolveFun%28js%3A%3Afrontend%3A%3AParseNode*%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* …
status-firefox18: unaffected → affected
status-firefox19: --- → affected
status-firefox20: --- → affected
status-firefox21: --- → affected
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 280 PN_NAME 307 PN_LIST 303 PN_FUNC 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.
status-firefox22: --- → affected
status-firefox23: --- → affected
status-firefox24: --- → affected
status-firefox25: --- → affected
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 (https://nightly.mozilla.org/) 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 (https://goo.gl/PNe90E). Thanks, Paul.
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(scoobidiver)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.