672262 - Firefox 8.0a1 Crash [@ js::Bindings::getLocalNameArray(JSContext*, js::Vector<JSAtom*, int, js::TempAllocPolicy>*) ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Marcia Knous [:marcia]]

Seen while looking at trunk crash stats - https://crash-stats.mozilla.com/report/list?signature=js::Bindings::getLocalNameArray%28JSContext*,%20js::Vector%3CJSAtom*,%20int,%20js::TempAllocPolicy%3E*%29

Crashes started up showing the 2011070600 build. Possible regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f27dc203e62&tochange=58101c64c83c

https://crash-stats.mozilla.com/report/index/6d77eb18-8561-4ee4-af93-bf0aa2110718

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	js::Bindings::getLocalNameArray 	js/src/jsscript.cpp:179
1 	xul.dll 	js::Interpret 	js/src/jsinterp.cpp:4594
2 	xul.dll 	xul.dll@0x3d703f 	
3 	xul.dll 	xul.dll@0x3d703f

Comment 1

[Jeff Walden [:Waldo]]

This is probably me via bug 646574.  I'll be all over this with a reproducible testcase.  :-)

Comment 2

[Robert Kaiser]

This is the #1 topcrash on Nightly right now - Jeff, could you try to figure things out from the crash stacks?

Comment 3

[Jeff Walden [:Waldo]]

It looks like the crash is consistently from the interpreter in either JSOP_GETUPVAR_DBG or JSOP_CALLUPVAR_DBG.  The getLocalNameArray call hasn't gotten to an interesting point in execution yet: the crash is on a line to grow the passed-in vector by a certain amount, leaving the storage uninitialized.  The crash is a read violation for 0x48 on x86, 0x70 on x86-64.  0x70 matches offsetof(JSScript, bindings) in my x86-64 debug build.  So maybe we're somehow getting a callupvar or getupvar in debug mode, and somehow the fun->script() has no bindings.  But that doesn't make much sense, because code before the likely regressor did an identical bit of dereferencing of fun->script().bindings, which should have crashed in basically the same way.

A testcase would still be quite helpful.  Since it appears we have opcodes implicating debug mode, there might be a better change of reproducing this with Firebug running.  But that doesn't make much sense, either, because the reports I semi-randomly selected didn't have extensions installed.  So, yeah.  Testcase still very much wanted.

Comment 4

[David Mandelin [:dmandelin]]

(In reply to comment #3)
> It looks like the crash is consistently from the interpreter in either
> JSOP_GETUPVAR_DBG or JSOP_CALLUPVAR_DBG.  The getLocalNameArray call hasn't
> gotten to an interesting point in execution yet: the crash is on a line to
> grow the passed-in vector by a certain amount, leaving the storage
> uninitialized.  The crash is a read violation for 0x48 on x86, 0x70 on
> x86-64.  0x70 matches offsetof(JSScript, bindings) in my x86-64 debug build.
> So maybe we're somehow getting a callupvar or getupvar in debug mode, and
> somehow the fun->script() has no bindings.  

Wouldn't that mean that fun->script() is null?

> But that doesn't make much
> sense, because code before the likely regressor did an identical bit of
> dereferencing of fun->script().bindings, which should have crashed in
> basically the same way.

Comment 5

[Jeff Walden [:Waldo]]

Er, yes, it would, sorry.  (I wrote the first half of the comment before realizing 0x70 == offsetof(JSScript, bindings).)  The subsequent point still remains true: if fun->script().bindings is a null-dereference now as part of this bug, it should have been before as well, or so I read the code.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Maybe I'm misreading something, but it seems like this stopped happening on 7/14. Did something relevant land around then?

Comment 7

[Robert Kaiser]

Interesting, yes, no crashes with a Build ID later than 20110713. Suggests that something landed on 14th that fixed this.

Comment 8

[Robert Kaiser]

(In reply to comment #7)
> Interesting, yes, no crashes with a Build ID later than 20110713. Suggests
> that something landed on 14th that fixed this.

Er, sorry, "landed on the 13th that fixed this in the build from the 14th" is correct.

Comment 9

[Marcia Knous [:marcia]]

Although this seems gone on the trunk, I do see some Aurora crashes from 20110807 with this signature - https://crash-stats.mozilla.com/report/index/dd5e390e-2d5a-4108-8c3b-f16902110807 is one example I see in crash stats.

Comment 10

[Marcia Knous [:marcia]]

This signature is showing up in the explosive report today for Firefox 7: https://crash-analysis.mozilla.com/rkaiser/2011-10-03/2011-10-03.firefox.7.explosiveness.html. Do we think this is the same issue as this bug or should I open a new one?

Comment 11

[Jeff Walden [:Waldo]]

I don't know, but given that the comments here are messy about whether anything was or wasn't happening, let's go with a new one.

Comment 12

[Marcia Knous [:marcia]]

Filed Bug 691847 per Comment 11.