Last Comment Bug 709863 - Crash [@ JSC::MacroAssemblerCodePtr::executableAddress]
: Crash [@ JSC::MacroAssemblerCodePtr::executableAddress]
[sg:dos] js-triage-done
: crash, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Mac OS X
-- critical (vote)
: mozilla11
Assigned To: Brian Hackett (:bhackett)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: jsfunfuzz 630996
  Show dependency treegraph
Reported: 2011-12-12 10:35 PST by Gary Kwong [:gkw] [:nth10sd]
Modified: 2011-12-16 06:14 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stack (6.67 KB, text/plain)
2011-12-12 10:35 PST, Gary Kwong [:gkw] [:nth10sd]
no flags Details
patch (1.70 KB, patch)
2011-12-12 17:13 PST, Brian Hackett (:bhackett)
dvander: review+
Details | Diff | Splinter Review

Description User image Gary Kwong [:gkw] [:nth10sd] 2011-12-12 10:35:13 PST
Created attachment 580963 [details]

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 User image Gary Kwong [:gkw] [:nth10sd] 2011-12-12 11:19:57 PST
For some strange reason, the testcase should be in the same directory as where one is executing the command.


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


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

works, but NOT:

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


~/<something>/js -m -a -d ../testcase.js
Comment 3 User image David Mandelin [:dmandelin] 2011-12-12 15:40:14 PST
I can't repro this on tip. I tried Win 7 and MacOS 10.6.
Comment 4 User image David Mandelin [:dmandelin] 2011-12-12 16:49:16 PST
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 User image Brian Hackett (:bhackett) 2011-12-12 17:13:33 PST
Created attachment 581117 [details] [diff] [review]

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 User image Gary Kwong [:gkw] [:nth10sd] 2011-12-12 17:16:13 PST
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 User image Gary Kwong [:gkw] [:nth10sd] 2011-12-12 17:18:00 PST
> 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 User image Brian Hackett (:bhackett) 2011-12-13 11:46:17 PST
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 User image Brian Hackett (:bhackett) 2011-12-15 09:08:59 PST
Comment 10 User image Ed Morley [:emorley] 2011-12-16 06:14:06 PST

Note You need to log in before you can comment on or make changes to this bug.