Closed
Bug 1139474
Opened 10 years ago
Closed 10 years ago
Crash [@ IsCacheableSetPropCallPropertyOp] with --unboxed-objects
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: decoder, Assigned: bhackett1024)
Details
(Keywords: crash, regression, testcase, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(1 file)
1.59 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision c5b90c003be8 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --enable-debug, run with --fuzzing-safe --thread-count=2 --unboxed-objects --ion-eager --ion-offthread-compile=off):
var gTestcases = new Array();
var gTc = gTestcases.length;
function TestCase(d) {
this.description = d;
gTestcases[gTc++] = this;
}
function jsTestDriverEnd() {
for (var i = 0; i < gTestcases.length; i++)
gTestcases[i].dump();
}
setJitCompilerOption("ion.warmup.trigger", 1);
for (var i = 0; i < 3; ++i)
jsTestDriverEnd();
loadFile('new TestCase (String(["678"])); new TestCase (String(["34 678"]));');
for (var i = 0; i < 4; ++i)
loadFile("jsTestDriverEnd();");
loadFile("new TestCase();");
function loadFile(lfVarx) {
try {
evaluate(lfVarx, { noScriptRval : true, compileAndGo : true });
} catch (lfVare) {}
}
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000850874 in IsCacheableSetPropCallPropertyOp (obj=..., obj@entry=(JSObject * const) 0x7ffff57000c0 [object Object], holder=..., holder@entry=(JSObject * const) 0x7ffff57000c0 [object Object], shape=shape@entry=0x1) at js/src/jit/IonCaches.cpp:2089
2089 if (shape->hasSlot())
#0 0x0000000000850874 in IsCacheableSetPropCallPropertyOp (obj=..., obj@entry=(JSObject * const) 0x7ffff57000c0 [object Object], holder=..., holder@entry=(JSObject * const) 0x7ffff57000c0 [object Object], shape=shape@entry=0x1) at js/src/jit/IonCaches.cpp:2089
#1 0x00000000008b4010 in CanAttachNativeSetProp (checkTypeset=0x7fffffff9840, shape=0x1, holder=(JSObject *) 0x7ffff57000c0 [object Object], needsTypeBarrier=<optimized out>, val=..., id=..., obj=(JSObject * const) 0x7ffff57000c0 [object Object], cx=0x1a32b50) at js/src/jit/IonCaches.cpp:2858
#2 js::jit::SetPropertyIC::update (cx=0x1a32b50, outerScript=0x7ffff565e448, cacheIndex=<optimized out>, obj=(JSObject * const) 0x7ffff57000c0 [object Object], value=JSVAL_VOID) at js/src/jit/IonCaches.cpp:2996
#3 0x00007ffff5587123 in ?? ()
#4 0x0000000000000000 in ?? ()
rax 0x1 1
rbx 0x7fffffff98c0 140737488328896
rcx 0x7fffffff98e0 140737488328928
rdx 0x7fffffff98c0 140737488328896
rsi 0x7ffff57000c0 140737311146176
rdi 0x1 1
rbp 0x7fffffff97d0 140737488328656
rsp 0x7fffffff97c0 140737488328640
r8 0x1b21440 28447808
r9 0x0 0
r10 0x7fffffff9a80 140737488329344
r11 0x1b20548 28443976
r12 0x1b20490 28443792
r13 0x7fffffff98b0 140737488328880
r14 0x1a32b50 27470672
r15 0x1b20548 28443976
rip 0x850874 <IsCacheableSetPropCallPropertyOp(JS::HandleObject, JS::HandleObject, js::HandleShape)+36>
=> 0x850874 <IsCacheableSetPropCallPropertyOp(JS::HandleObject, JS::HandleObject, js::HandleShape)+36>: testb $0x40,0x14(%rdi)
0x850878 <IsCacheableSetPropCallPropertyOp(JS::HandleObject, JS::HandleObject, js::HandleShape)+40>: jne 0x850888 <IsCacheableSetPropCallPropertyOp(JS::HandleObject, JS::HandleObject, js::HandleShape)+56>
Comment 1•10 years ago
|
||
So shape=0x1 is clearly the issue, right?
I don't see anything in CanAttachNativeSetProp that would filter out non-native objects per se, so if LookupPropertyOure on an unboxed object will return shape == 0x1 we would run into this.
Flags: needinfo?(bhackett1024)
Assignee | ||
Comment 2•10 years ago
|
||
The paths for attaching Ion ICs and, to a lesser extent, baseline ICs, are pretty convoluted, and especially so given the unboxed objects stuff. After bug 1137180 lands I'd like to make a pass over this stuff and clean things up some.
FWIW I ran into this in bug 1137180 and the patch there includes this fix as well.
Assignee: nobody → bhackett1024
Flags: needinfo?(bhackett1024)
Attachment #8573448 -
Flags: review?(jdemooij)
Reporter | ||
Updated•10 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 3•10 years ago
|
||
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===
The "good" changeset has the timestamp "20150303042544" and the hash "c75a393d7bfb".
The "bad" changeset has the timestamp "20150303043344" and the hash "9e86bfdf6bd8".
Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c75a393d7bfb&tochange=9e86bfdf6bd8
Comment 4•10 years ago
|
||
Comment on attachment 8573448 [details] [diff] [review]
patch
Review of attachment 8573448 [details] [diff] [review]:
-----------------------------------------------------------------
(In reply to Brian Hackett (:bhackett) from comment #2)
> After bug 1137180 lands I'd like to make a pass over this stuff and clean things
> up some.
Cool. Also, LookupPropertyPure returning a 0x1 shape in some cases is a footgun. It'd be nice to have a LookupResult class or something to make it obvious it's not always a valid-Shape-or-null. (Or maybe that's the part you decided to clean up :)
Attachment #8573448 -
Flags: review?(jdemooij) → review+
Assignee | ||
Comment 5•10 years ago
|
||
I'd been planning on cleaning up the JIT caches primarily, but you're right that the 0x1 shape thing is ugly and would be handled much better as a specialized class similar to TaggedProto. I'll try to fix that too.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d43fb3fe56f0
Comment 6•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•