Crash [@ JSC::MacroAssemblerCodePtr::executableAddress]

RESOLVED FIXED in mozilla11

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: gkw, Assigned: bhackett)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
mozilla11
x86_64
Mac OS X
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos] js-triage-done, crash signature)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 580963 [details]
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.
(Reporter)

Comment 2

6 years ago
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
I can't repro this on tip. I tried Win 7 and MacOS 10.6.
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.
Assignee: general → bhackett1024
(Assignee)

Comment 5

6 years ago
Created attachment 581117 [details] [diff] [review]
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.
Attachment #581117 - Flags: review?(dvander)
Attachment #581117 - Flags: review?(dvander) → review+
(Reporter)

Comment 6

6 years ago
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])
Whiteboard: js-triage-needed → js-triage-done
(Reporter)

Comment 7

6 years ago
> 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.
(Assignee)

Comment 8

6 years ago
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.
(Reporter)

Updated

6 years ago
Whiteboard: js-triage-done → [sg:dos] js-triage-done
Group: core-security

Updated

6 years ago
Crash Signature: [@ JSC::MacroAssemblerCodePtr::executableAddress]
(Assignee)

Comment 9

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8780747bbc5c
https://hg.mozilla.org/mozilla-central/rev/8780747bbc5c
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in before you can comment on or make changes to this bug.