Closed Bug 1138912 Opened 11 years ago Closed 11 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+
Status: NEW → RESOLVED
Closed: 11 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: