Closed Bug 1153057 Opened 9 years ago Closed 9 years ago

Crash [@ js::gc::Cell::storeBuffer] or [@ js::HeapPtr] or Assertion failure: isObject(), at dist/include/js/Value.h

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: gkw, Assigned: efaust)

References

Details

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

Crash Data

Attachments

(3 files)

({
  "0"
  ()
  eval()
})

asserts js debug shell on m-c changeset dd32e3ff3717 with --fuzzing-safe --no-threads --ion-eager at Assertion failure: isObject(), at dist/include/js/Value.h and crashes js opt shell at js::gc::Cell::storeBuffer with js::HeapPtr on the stack.

Configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/fuzzing/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build" -r dd32e3ff3717

=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150408173433" and the hash "dd23c0a059f6".
The "bad" changeset has the timestamp "20150408174235" and the hash "876c8ee6b132".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dd23c0a059f6&tochange=876c8ee6b132

Eric, is bug 1141862 a likely regressor?
Flags: needinfo?(efaustbmo)
Attached file stack
(lldb) bt 5
* thread #1: tid = 0xeee32, 0x000000010001ad0d js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`JS::Value::toObject(this=<unavailable>) const + 189 at Value.h:1237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010001ad0d js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`JS::Value::toObject(this=<unavailable>) const + 189 at Value.h:1237
    frame #1: 0x00000001002023e3 js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`Interpret(cx=0x0000000101ea5180, state=0x00007fff5fbfef58) + 81715 at Interpreter.cpp:3959
    frame #2: 0x00000001001ee47f js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`js::RunScript(cx=0x0000000101ea5180, state=0x00007fff5fbfef58) + 335 at Interpreter.cpp:654
    frame #3: 0x0000000100204407 js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`js::ExecuteKernel(cx=0x0000000101ea5180, script=<unavailable>, scopeChainArg=0x000000010385a060, thisv=0x00007fff5fbff068, type=EXECUTE_GLOBAL, evalInFrame=<unavailable>, result=<unavailable>) + 1383 at Interpreter.cpp:879
    frame #4: 0x000000010020475f js-dbg-64-dm-nsprBuild-darwin-dd32e3ff3717`js::Execute(cx=0x0000000101ea5180, script=<unavailable>, scopeChainArg=<unavailable>, rval=0x0000000000000000) + 431 at Interpreter.cpp:918
(lldb)
Attached file stack of opt crash
(lldb) bt 5
* thread #1: tid = 0xef009, 0x0000000100475350 js-64-dm-nsprBuild-darwin-dd32e3ff3717`js::HeapPtr<JS::Value>::set(JS::Value const&) [inlined] js::gc::Cell::storeBuffer() const + 3 at Heap.h:1301, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffff0)
  * frame #0: 0x0000000100475350 js-64-dm-nsprBuild-darwin-dd32e3ff3717`js::HeapPtr<JS::Value>::set(JS::Value const&) [inlined] js::gc::Cell::storeBuffer() const + 3 at Heap.h:1301
    frame #1: 0x000000010047534d js-64-dm-nsprBuild-darwin-dd32e3ff3717`js::HeapPtr<JS::Value>::set(JS::Value const&) + 5 at Barrier.h:370
    frame #2: 0x0000000100475348 js-64-dm-nsprBuild-darwin-dd32e3ff3717`js::HeapPtr<JS::Value>::set(JS::Value const&) [inlined] js::HeapPtr<JS::Value>::post(this=0x0000000103260fe0) at Barrier.h:556
    frame #3: 0x0000000100475348 js-64-dm-nsprBuild-darwin-dd32e3ff3717`js::HeapPtr<JS::Value>::set(this=0x0000000103260fe0, v=<unavailable>) + 200 at Barrier.h:569
    frame #4: 0x000000010014e9f6 js-64-dm-nsprBuild-darwin-dd32e3ff3717`Interpret(JSContext*, js::RunState&) [inlined] js::HeapPtr<JS::Value>::operator=(this=<unavailable>, p=<unavailable>) + 61142 at Barrier.h:553
(lldb)
Crash Signature: [@ js::gc::Cell::storeBuffer] [@ js::HeapPtr] → [@ js::gc::Cell::storeBuffer] [@ js::HeapPtr]
Attached patch FixSplinter Review
The bytecode we emitted was well-meaning but not correct.

If the function object being installed required an ELEM instruction (via a CPN, or in this case, a string identifier), we had the wrong stack offset for the [[HomeObject]] when we tried to initialize it for the function object.

This should take care of that.

Also, add a test for this case, clean up a random piece of spew in a test, and remove erroneous JOF flags from JSOP_INITHOMEOBJECT.
Assignee: nobody → efaustbmo
Status: NEW → ASSIGNED
Flags: needinfo?(efaustbmo)
Attachment #8591048 - Flags: review?(jorendorff)
Comment on attachment 8591048 [details] [diff] [review]
Fix

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

Please also add the actual test case from comment 0, as a jit-test.

::: js/src/vm/Interpreter.cpp
@@ +3978,5 @@
>      MOZ_ASSERT(func->isMethod());
>  
>      /* Load the home object */
>      RootedNativeObject& obj = rootNativeObject0;
> +    obj = &REGS.sp[-2 - GET_UINT8(REGS.pc)].toObject().as<NativeObject>();

Please assert something like what JSOP_PICK does here:
    MOZ_ASSERT(REGS.stackDepth() >= i + 1);
Attachment #8591048 - Flags: review?(jorendorff) → review+
https://hg.mozilla.org/mozilla-central/rev/220c1eb8eafe
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Fixed, clearing ni?
Flags: needinfo?(efaustbmo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: