Closed
Bug 926596
Opened 11 years ago
Closed 11 years ago
Crash [@ js::BaseShape::lookupUnowned]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla27
People
(Reporter: decoder, Assigned: shu)
Details
(Keywords: crash, testcase, Whiteboard: [qa-])
Crash Data
Attachments
(2 files)
892 bytes,
text/plain
|
Details | |
1.59 KB,
patch
|
nmatsakis
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision 211337f7fb83 (threadsafe build, run with --fuzzing-safe --thread-count=2 --ion-compile-try-catch --ion-eager --ion-eager --ion-regalloc=backtracking --ion-parallel-compile=on): gczeal(4); function mergeSorted(l1, l2) { var result = []; var i1 = 0, i2 = 0, j = 0; result["1\u000C-\u000C1"] = l1[i1++]; return result; } var elts = []; for (var i = 0; i < 2048; i++) elts[i] = true; elts.scanPar(mergeSorted);
Reporter | ||
Comment 1•11 years ago
|
||
The crash is from an optimized build. In a debug build I get asserts like in bug, but shu mentioned that this is a different bug. Here's a crash trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf19fdb40 (LWP 12219)] js::BaseShape::lookupUnowned (cx=<optimized out>, base=...) at js/src/vm/Shape.cpp:1454 1454 if (!table.initialized()) #0 js::BaseShape::lookupUnowned (cx=<optimized out>, base=...) at js/src/vm/Shape.cpp:1454 #1 0x081095b7 in GetOrLookupUnownedBaseShape<(js::ExecutionMode)1> (base=..., cx=0xf19fd1f0) at js/src/vm/Shape.cpp:566 #2 JSObject::addPropertyInternal<(js::ExecutionMode)1> (cx=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, getter=0, setter=0, slot=16777215, attrs=1, flags=0, shortid=0, spp=0x0, allowDictionary=true) at js/src/vm/Shape.cpp:632 #3 0x0810a4ef in JSObject::putProperty<(js::ExecutionMode)1> (cx=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, getter=0, setter=0, slot=16777215, attrs=1, flags=0, shortid=0) at js/src/vm/Shape.cpp:766 #4 0x0821c71e in DefinePropertyOrElement<(js::ExecutionMode)1> (setterIsStrict=false, callSetterAfterwards=true, value=$jsval(-nan(0xfff8200000000)), shortid=0, flags=0, attrs=1, setter=0x8176e00 <JS_StrictPropertyStub(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, bool, JS::MutableHandle<JS::Value>)>, getter=0x8176df0 <JS_PropertyStub(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, JS::MutableHandle<JS::Value>)>, id=-150913792, obj=(JSObject * const) 0xf6f7a010 [object Array], cx=0xf19fd1f0) at js/src/jsobj.cpp:3548 #5 js::baseops::SetPropertyHelper<(js::ExecutionMode)1> (cxArg=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], receiver=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, defineHow=0, vp=$jsval(-nan(0xfff8200000000)), strict=false) at js/src/jsobj.cpp:4866 #6 0x0836a96b in js::jit::SetPropertyParIC::update (slice=0xf19fd1f0, cacheIndex=0, obj=(JSObject * const) 0xf6f7a010 [object Array], value=$jsval(-nan(0xfff8200000000))) at js/src/jit/IonCaches.cpp:2896 #7 0xf72ae2e9 in ?? () eax 0x0 0 eip 0x8101939 <js::BaseShape::lookupUnowned(js::ThreadSafeContext*, js::StackBaseShape const&)+25> => 0x8101939 <js::BaseShape::lookupUnowned(js::ThreadSafeContext*, js::StackBaseShape const&)+25>: mov 0xec(%eax),%eax I've marked this s-s because I've seen various crashes with this signature, but varying crash addresses, so I assume it might be controllable.
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
And I again forgot to remove unnecessary options in comment 0: No options are required for this test.
Assignee | ||
Comment 4•11 years ago
|
||
Another one for the "how did this ever work" department.
Attachment #816852 -
Flags: review?
Assignee | ||
Updated•11 years ago
|
Assignee: general → shu
Status: NEW → ASSIGNED
Assignee | ||
Updated•11 years ago
|
Attachment #816852 -
Flags: review? → review?(nmatsakis)
Assignee | ||
Updated•11 years ago
|
status-firefox24:
--- → disabled
status-firefox25:
--- → disabled
status-firefox26:
--- → disabled
status-firefox27:
--- → affected
Assignee | ||
Comment 5•11 years ago
|
||
Christian, this will always result in a NULL (or +offset from NULL) access. What sec rating should this have?
Reporter | ||
Comment 6•11 years ago
|
||
(In reply to Shu-yu Guo [:shu] from comment #5) > Christian, this will always result in a NULL (or +offset from NULL) access. > What sec rating should this have? What is the offset limited by? I've seen an offset of 0x150 in one case. If the offset can be reasonably large, then this could be sec-high or critical. If it cannot grow to any useful amount, then it's probably not a security bug.
Updated•11 years ago
|
Attachment #816852 -
Flags: review?(nmatsakis) → review+
Comment 7•11 years ago
|
||
fixed in mozilla-central https://hg.mozilla.org/mozilla-central/rev/da7c23b2d1c7
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Comment 8•11 years ago
|
||
I discussed this with :shu on irc Although some of the code existed before b2g18 branched, the code is ifdef'd out for everything but nightly builds. Marking b2g18 as disabled
status-b2g18:
--- → disabled
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•