Closed Bug 1138912 Opened 9 years ago Closed 9 years ago

Crash [@ js::NewObjectOperationWithTemplate] or Assertion failure: isObject(), at dist/include/js/Value.h:1240

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: decoder, Assigned: bhackett1024)

References

Details

(4 keywords, Whiteboard: [jsbugmon:update][fuzzblocker])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 0b3c520002ad (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-debug, run with --ion-eager --no-threads):

function test() {
    var rooter = {};
    for (var i = 0; i < 14; i++) {}
    i.foo = "bar";
}
test();
setObjectMetadataCallback(true);
test();



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
js::NewObjectOperationWithTemplate (cx=cx@entry=0x16bdce0, templateObject=templateObject@entry=...) at js/src/vm/Interpreter.cpp:4197
4197	    NewObjectKind newKind = templateObject->group()->shouldPreTenure() ? TenuredObject : GenericObject;
#0  js::NewObjectOperationWithTemplate (cx=cx@entry=0x16bdce0, templateObject=templateObject@entry=...) at js/src/vm/Interpreter.cpp:4197
#1  0x00000000007730f5 in js::jit::RNewObject::recover (this=0x7fffffffaf98, cx=0x16bdce0, iter=...) at js/src/jit/Recover.cpp:1180
#2  0x0000000000736804 in js::jit::SnapshotIterator::computeInstructionResults (this=this@entry=0x7fffffffb2a0, cx=cx@entry=0x16bdce0, results=results@entry=0x7fffffffc400) at js/src/jit/JitFrames.cpp:2182
#3  0x000000000073698d in js::jit::SnapshotIterator::initInstructionResults (this=this@entry=0x7fffffffb9d0, fallback=...) at js/src/jit/JitFrames.cpp:2136
#4  0x00000000006c3848 in SnapshotIteratorForBailout::init (this=this@entry=0x7fffffffb9d0, cx=cx@entry=0x16bdce0) at js/src/jit/BaselineBailouts.cpp:435
#5  0x000000000069c380 in js::jit::BailoutIonToBaseline (cx=cx@entry=0x16bdce0, activation=0x7fffffffc380, iter=..., invalidate=invalidate@entry=false, bailoutInfo=bailoutInfo@entry=0x7fffffffc068, excInfo=excInfo@entry=0x0) at js/src/jit/BaselineBailouts.cpp:1457
#6  0x000000000061c308 in js::jit::Bailout (sp=<optimized out>, bailoutInfo=0x7fffffffc068) at js/src/jit/Bailouts.cpp:54
#7  0x00007ffff7f74441 in ?? ()
#8  0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x16bdce0	23846112
rcx	0x6fb270	7320176
rdx	0x7fffffffffff	140737488355327
rsi	0x0	0
rdi	0x16bdce0	23846112
rbp	0x7fffffffaea0	140737488334496
rsp	0x7fffffffade0	140737488334304
r8	0x17c04c8	24904904
r9	0x0	0
r10	0x17c04da	24904922
r11	0x0	0
r12	0x7fffffffaf98	140737488334744
r13	0x7fffffffaf40	140737488334656
r14	0x16bdce0	23846112
r15	0x7fffffffbd40	140737488338240
rip	0x53c9d3 <js::NewObjectOperationWithTemplate(JSContext*, JS::Handle<JSObject*>)+35>
=> 0x53c9d3 <js::NewObjectOperationWithTemplate(JSContext*, JS::Handle<JSObject*>)+35>:	mov    0x8(%rax),%r12
   0x53c9d7 <js::NewObjectOperationWithTemplate(JSContext*, JS::Handle<JSObject*>)+39>:	mov    %r12,%rdi
Marking s-s because I also just found a test with the same signature that contains gczeal instead of setObjectMetadataCallback:


function f(N) {
  for (var i = 0; i != N; ++i) {
    var obj0 = {}, obj1 = {}, obj2 = {};
    obj2['b'+i] = 0;
        for (var k in obj2) gczeal(2);
  }
}
(function() { f(10); })();
Group: core-security
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150228225928" and the hash "60a37ae57d9c".
The "bad" changeset has the timestamp "20150301143328" and the hash "6470d649e1bb".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=60a37ae57d9c&tochange=6470d649e1bb

Brian, is bug 1135423 a likely regressor? (applies for both testcases)
Blocks: 1135423
Flags: needinfo?(bhackett1024)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Attached patch patchSplinter Review
MNewObject can't assume it has a non-null template object anymore.  I don't know if there's a better way of fixing this but in Recover.cpp I didn't see any obvious way to get the script/pc for the resume point attached to the MNewObject being recovered.
Assignee: nobody → bhackett1024
Flags: needinfo?(bhackett1024)
Attachment #8573442 - Flags: review?(jdemooij)
NULL deref, not s-s.
Group: core-security
This is a topcrasher in fuzzing, marking fuzzblocker.
Whiteboard: [jsbugmon:update] → [jsbugmon:update][fuzzblocker]
Comment on attachment 8573442 [details] [diff] [review]
patch

Review of attachment 8573442 [details] [diff] [review]:
-----------------------------------------------------------------

Seems reasonable.
Attachment #8573442 - Flags: review?(jdemooij) → review+
https://hg.mozilla.org/mozilla-central/rev/98874cdde2f9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: