898867 - Crash in js::ObjectImpl::getSlot(unsigned int)

Status: RESOLVED DUPLICATE of bug 897919

(Core :: JavaScript Engine, defect)

Description

[Patrick Westerhoff]

This bug was filed from the Socorro interface and is 
report bp-bc130ddf-d33c-446e-828d-67c7c2130728 .
 ============================================================= 

Crash on Nightly 25.0a1 (2013-07-28)

Steps to reproduce the crash:

1. Go to about:blank
2. Open the console (Ctrl+K)
3. Enter this to load the d3.js library:
     var s = document.createElement('script');s.src = 'http://d3js.org/d3.v2.min.js?2.10.0';document.body.appendChild(s);
4. Enter:
     d3.scale.linear()


My crash reports:
https://crash-stats.mozilla.com/report/index/7214ac71-a061-45ee-8eed-1cd352130728
https://crash-stats.mozilla.com/report/index/6c2e4214-ae68-4c54-858e-4c2702130728
https://crash-stats.mozilla.com/report/index/60b8ae64-15ef-4e51-9275-05a522130728
https://crash-stats.mozilla.com/report/index/bc130ddf-d33c-446e-828d-67c7c2130728

This is possibly related to #883562.

Comment 1

[Loic]

Regression range:
good=2013-07-19
bad=2013-07-20
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af4e3ce8c487&tochange=bf73e10f5e54

Comment 2

[Alice0775 White]

Regression window (fx)
Good:
http://hg.mozilla.org/integration/fx-team/rev/9c0275e6303e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130718 Firefox/25.0 ID:20130718014148
Bad:
http://hg.mozilla.org/integration/fx-team/rev/c3f39498c164
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130718 Firefox/25.0 ID:20130718041649
Pushlog:
http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=9c0275e6303e&tochange=c3f39498c164

Comment 3

[Alice0775 White]

In local build
Last Good: 5be325efcdcf
First Bad: 5d860e628af6

Triggered by
5d860e628af6	Panos Astithas — Implement backend support for breaking on DOM events and retrieving all the event listeners on a page (bug 832982); r=rcampbell,smaug

Comment 4

[bhavana bajaj [:bajaj]]

Needsinfo Panos to help understand if the exacts steps have to be followed to crash the issue or this could be a generic scenario in the console ?

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: mac-debug-crash.log

I can't see how the main change in this patch could be the cause of this crash, so my guess is that the culprit is one of the minor but necessary refactorings that were included.

On a debug build in OS X I get a probably more helpful stack trace (attached):

Assertion failure: hasScript(), at /Users/past/src/fx-team/js/src/jsfun.h:262

0  DebuggerObject_getScript(JSContext*, unsigned int, JS::Value*) + 699 (RootingAPI.h:676)
1  js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 77 (jscntxtinlines.h:225)
2  js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) + 367 (Interpreter.cpp:479)
3  js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) + 451 (Interpreter.cpp:536)
4  js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) + 86 (Interpreter.cpp:607)
5  js::Shape::get(JSContext*, JS::Handle<JSObject*>, JSObject*, JSObject*, JS::MutableHandle<JS::Value>) + 80 (Shape-inl.h:263)
6  int NativeGetInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::HandleType, unsigned int, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) + 406 (jsobj.cpp:4029)
7  int GetPropertyHelperInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, unsigned int, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) + 259 (jsobj.cpp:4200)
8  js::GetPropertyHelper(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, unsigned int, JS::MutableHandle<JS::Value>) + 18 (jsobj.cpp:4209)
9  GetPropertyOperation(JSContext*, js::StackFrame*, JS::Handle<JSScript*>, unsigned char*, JS::MutableHandle<JS::Value>, JS::MutableHandle<JS::Value>) + 759 (Interpreter.cpp:289)
10 Interpret(JSContext*, js::RunState&) + 12216 (Interpreter.cpp:2353)
11 js::RunScript(JSContext*, js::RunState&) + 337 (Interpreter.cpp:443)

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

And it's actually this line that is triggering the crash:

https://hg.mozilla.org/mozilla-central/diff/5d860e628af6/toolkit/devtools/server/actors/script.js#l1.456

I have no idea why.

Comment 7

[Jim Blandy :jimb]

I think this may be a duplicate of bug 897919.

SpiderMonkey now puts off actually allocating JSScripts for some functions, in two circumstances:

- Sometimes we can save time by not generating bytecode for a function until it's first called; until that point, the function simply points to its source code; we invoke the byte compiler to de-lazy it.

- Sometimes a function has a self-hosted implementation. We compile all self-hosted functions to bytecode in a secret compartment at startup; then user compartments get functions that don't have their own JSScripts, but instead clone the self-hosted compartment's JSScript the first time they're called. So here, delazifying means script cloning.

JSFunction has various accessors for the script: some de-lazify if needed; some return NULL if it's lazy; some assert that it's not lazy.

For some reason, Debugger was changed to use nonLazyScript, which asserts that it's not lazy. There's no justification for this - of course Debugger might run across lazy functions. But mysteriously, the unit tests never caught this.

Comment 8

[Alex Keybl [:akeybl]]

jimb, can you speak to the criticality of this bug given the fact that it's a regression but not a topcrash?

We're trying to determine whether or not this should be investigated as a priority, and therefore tracked.

Comment 9

[Jim Blandy :jimb]

Bug 897919 has been fixed; I'm pretty sure this is just a duplicate of that. I can't reproduce it with the given steps in a build from M-C pulled yesterday.
xk