709863 - Crash [@ JSC::MacroAssemblerCodePtr::executableAddress]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

The upcoming testcase crashes js debug shell on m-c changeset 63bff373cb94 with -m, -a and -d at JSC::MacroAssemblerCodePtr::executableAddress

s-s on the safe side because a previous bug 686107 was s-s.

This was found using a combination of jsfunfuzz and jandem's method fuzzer.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

For some strange reason, the testcase should be in the same directory as where one is executing the command.

e.g.

./js -m -a -d testcase.js

or

~/<something>/js -m -a -d testcase.js

works, but NOT:

./js -m -a -d ../testcase.js

nor

~/<something>/js -m -a -d ../testcase.js

Comment 3

[David Mandelin [:dmandelin]]

I can't repro this on tip. I tried Win 7 and MacOS 10.6.

Comment 4

[David Mandelin [:dmandelin]]

Debugged this on Gary's machine. It is an NPE. jit() goes to NULL during the call to nativeLookup in ic::SetGlobalName. I verified that a GC also occurs during that call. So I think it will always be an NPE, but I'll let Brian check on that--he says it's an ObjShrink regression.

Comment 5

[Brian Hackett [Laid off!]]

Attachment: patch

Before ObjShrink, JSObject::native{Search,Lookup} could not GC --- they search for a native property on the object, possibly malloc'ing a property table for the last property (malloc cannot GC).  With objshrink, the property table allocation needs to allocate an owned base shape for the shape, which is a GC thing allocation that can trigger GC.  This patch fixes SetGlobalName and a similar case in GetGlobalName; there aren't any other places where native lookups are performed directly by the IC code.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Thanks go out to dmandelin for helping to debug this.

Brian, is this always a null deref? (we can then set the sg: rating to [sg:dos])

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> Brian, is this always a null deref? (we can then set the sg: rating to
> [sg:dos])

Also, will adding assertions help us to trigger similar bugs in the future? Does adding assertions apply to this case? This was particularly hard to trigger and reduce, fwiw.

Comment 8

[Brian Hackett [Laid off!]]

I think this always be a null deref.  There really isn't any way to assert this, it requires the GC to happen in just a particular spot to behave at all incorrectly and afterwards will crash regardless.

Comment 9

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8780747bbc5c

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8780747bbc5c