Closed Bug 884194 Opened 12 years ago Closed 12 years ago

crash in Interpret

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
24 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla24
Tracking Flags:
Tracking Status
firefox23 --- unaffected
firefox24 + verified

People

(Reporter: scoobidiver, Assigned: bhackett1024)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file)

patch
5.79 KB, patch
luke
: review+
Details | Diff | Splinter Review
It first showed up in 24.0a1/20130615, likely a signature morphing of bug 682573, and started spiking in 24.0a1/20130617 (#4 top crasher in that build so higher than bug 682573 in other channels). The regression ranges are: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b197bed90a98&tochange=3d16d59c9317 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36da3cb92193&tochange=834c8941ae24 (spike) Stack traces are various: Frame Module Signature Source 0 mozjs.dll Interpret js/src/vm/Interpreter.cpp:2465 1 mozjs.dll js::RunScript js/src/vm/Interpreter.cpp:328 2 mozjs.dll js::Invoke js/src/vm/Interpreter.cpp:400 3 mozjs.dll js_fun_call js/src/jsfun.cpp:828 Frame Module Signature Source 0 mozjs.dll Interpret js/src/vm/Interpreter.cpp:2465 1 mozjs.dll js::RunScript js/src/vm/Interpreter.cpp:328 2 mozjs.dll js::Invoke js/src/vm/Interpreter.cpp:437 3 mozjs.dll js::ion::DoCallFallback js/src/ion/BaselineIC.cpp:6997 Frame Module Signature Source 0 libxul.so Interpret js/src/vm/Interpreter.cpp:2465 1 libxul.so void js::assertSameCompartment<JS::Handle<JSObject*> > js/src/jscntxtinlines.h:206 2 libxul.so JS_BasicObjectToString js/src/builtin/Object.cpp:301 3 libxul.so JS_EnumerateStub js/src/jsapi.cpp:3235 4 libxul.so obj_toString js/src/builtin/Object.cpp:328 Frame Module Signature Source 0 mozjs.dll Interpret js/src/vm/Interpreter.cpp:1852 1 mozjs.dll js::RunScript js/src/vm/Interpreter.cpp:328 2 mozjs.dll js::ExecuteKernel js/src/vm/Interpreter.cpp:533 3 mozjs.dll js::Execute js/src/vm/Interpreter.cpp:573 4 mozjs.dll JS::Evaluate js/src/jsapi.cpp:5690 5 xul.dll nsJSContext::EvaluateString dom/base/nsJSEnvironment.cpp:1278 6 xul.dll nsScriptLoader::EvaluateScript content/base/src/nsScriptLoader.cpp:854 7 xul.dll nsScriptLoader::ProcessRequest content/base/src/nsScriptLoader.cpp:742 ... Frame Module Signature Source 0 mozjs.dll Interpret js/src/vm/Interpreter.cpp:2465 1 mozjs.dll js::RunScript js/src/vm/Interpreter.cpp:348 2 mozjs.dll js::Invoke js/src/vm/Interpreter.cpp:437 3 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5886 4 xul.dll mozilla::dom::Function::Call obj-firefox/dom/bindings/FunctionBinding.cpp:39 5 xul.dll mozilla::dom::Function::Call<nsCOMPtr<nsISupports> > obj-firefox/dist/include/mozilla/dom/FunctionBinding.h:52 6 xul.dll nsGlobalWindow::RunTimeoutHandler dom/base/nsGlobalWindow.cpp:10209 ... Frame Module Signature Source 0 mozjs.dll Interpret js/src/vm/Interpreter.cpp:2465 1 xul.dll nsDisplayBackgroundImage::AppendBackgroundItemsToTop layout/base/nsDisplayList.cpp:1643 2 xul.dll nsBoxFrame::BuildDisplayList layout/xul/base/src/nsBoxFrame.cpp:1346 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=Interpret
bp-9a8a2540-dd26-4388-bd31-2af262130618 http://hg.mozilla.org/mozilla-central/rev/4e5983de6e3b Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20130618 Firefox/24.0 ID:20130618031335 I can reproduce the crash in Linux with STR of Bug 884156
bp-6c8f9d1c-2792-431a-8e0e-48a032130619 Steps To Reproduce: 1. Open Web Console 2. Open http://blog.feedly.com/2013/03/14/google-reader/ Actual Results: Browser crashes
Regression window with STR of comment#2 is as follows. Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/8a22078d93b2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130615 Firefox/24.0 ID:20130616061322 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/91f620586eb8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130615 Firefox/24.0 ID:20130616092524 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8a22078d93b2&tochange=91f620586eb8 Regressed by: 91f620586eb8 Brian Hackett — Bug 883630 - Watch for lazy functions when iterating inline Ion frames, clean up methods for accessing function scripts.
Blocks: 883630
Keywords: reproducible
Annoying bug, Firefox crashes on various websites when the web console is open.
Attached patch patch — — Splinter Review
Sorry for the delay. The getExistingScript() function added in the blamed cset does not update fun->isHeavyweight() and fun->nargs as it should. If such functions, or their clones, show up on scope chains then scope objects do not get pushed on the scope chain when they should and havoc ensues. The attached patch fixes this and renames getExistingScript per an earlier review request.
Assignee: general → bhackett1024
Attachment #765442 - Flags: review?(luke)
Comment on attachment 765442 [details] [diff] [review] patch r+ for this quick fix. To make this all less error prone, could we change this so that JSFunction fields don't have to be updated lazily? In particular: - it seems like we could move the heavyweight bit to JSScript - fun->nargs belongs on JSFunction but could it be set eagerly/correctly when initially creating the lazy JSFunction?
Attachment #765442 - Flags: review?(luke) → review+
(In reply to Luke Wagner [:luke] from comment #6) > To make this all less error prone, could we change this so that JSFunction > fields don't have to be updated lazily? In particular: > - it seems like we could move the heavyweight bit to JSScript > - fun->nargs belongs on JSFunction but could it be set eagerly/correctly > when initially creating the lazy JSFunction? Yeah, I thought about this but the problem is with nargs. We can't set the bit eagerly for the JSFunction on delazification because at that point there may be many clones pointing to the same LazyScript, all of which would need to be updated. So handling nargs correctly would require that they be tracked in the JSScript for interpreted functions, which could bloat JSScript without shrinking JSFunction. Now, JSScript has a PADDING16 field but it'd be nice to leave that as padding and find other stuff to kill or move (version, staticLevel, length, natoms ...) to shrink the structure further.
Actually, I'm confused now: looking at functionArgsAndBody, it seems like we will correctly set fun->nargs in functionArgsAndBodyGeneric. How do a lazy function's nargs get to be wrong?
(In reply to Luke Wagner [:luke] from comment #8) > Actually, I'm confused now: looking at functionArgsAndBody, it seems like we > will correctly set fun->nargs in functionArgsAndBodyGeneric. How do a lazy > function's nargs get to be wrong? Oops, yes, you're right, ParseContext<SyntaxParseHandler>::define updates args_ so that fun->nargs should always be right. I'll write a patch to kill JSFunction::HEAVYWEIGHT.
Great, thanks!
Blocks: 884156
https://hg.mozilla.org/mozilla-central/rev/208bb5954938
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox24: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Not able to reproduce the crash following STR from Bug 883562 on FF 24b6. Not marking as Verified because there are still lots of crashes on Soccoro on FF 24b5 which was released after Ed's pushlog from Comment 12 https://crash-stats.mozilla.com/report/list?signature=Interpret&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-08-27+14%3A00%3A00&range_value=1
I wasn't able to reproduce this crash on Win 7 64bit, using STR from comment 2 and bug Bug 884156, so I tried on Ubuntu 13.04 32bit, and I managed to reproduce the crash using STR from Bug 884156. This crash doesn't reproduce with Firefox 24 beta 9 (build ID: 20130905180733) on Ubuntu, with both STR. Also, there aren't many crashes since 24.0b5 in Socorro, regarding last month: https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-08-27&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=Interpret As a conclusion, marking this verified fixed.
status-firefox24: fixed → verified
QA Contact: manuela.muntean
I'm not sure this is fixed as I just got this crash after upgrading to Firefox 24 on Win 7 64bit. I've never had this crash prior to that. d9bab320-d60e-4da4-8885-b24782130918
Link to your CR: https://crash-stats.mozilla.com/report/index/d9bab320-d60e-4da4-8885-b24782130918 Are you able to crash by following the STR in comment #2?
Flags: needinfo?(morac99-firefox2)
No, I've started getting a variety of different crash signatures (usually including js::GCSlice(JSRuntime *,js::JSGCInvocationKind,JS::gcreason::Reason,__int64)) so it might be something else.
Flags: needinfo?(morac99-firefox2)
Ok, open a new bug report if you're able to find some STR to reproduce these new crashes.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: