Closed Bug 984766 Opened 6 years ago Closed 6 years ago

Crash [@ js::CurrentThreadCanAccessZone] or Assertion failure: addr % CellSize == 0, at gc/Heap.h or Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at dist/include/js/HeapAPI.h

Categories

(Core :: JavaScript Engine: JIT, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox30 --- unaffected
firefox31 --- verified
firefox-esr24 --- unaffected

People

(Reporter: gkw, Assigned: bhackett)

References

(Blocks 1 open bug)

Details

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

Attachments

(2 files)

Attached file stack
x = ArrayBuffer(4)
x.f = (function() {})
Uint16Array(x).set(JSON.parse)
gcslice()

asserts js debug shell on m-c changeset 082761b7bc54 without any CLI arguments at Assertion failure: addr % CellSize == 0, at gc/Heap.h

An upcoming variant asserts at Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at dist/include/js/HeapAPI.h or crashes at js::CurrentThreadCanAccessZone

$ ./js-dbg-64-ts-darwin-082761b7bc54 53.js
***
Targeting SpiderMonkey / Gecko (trunk).
Segmentation fault: 11

$ ./js-dbg-64-ts-darwin-082761b7bc54 --ion-parallel-compile=off --ion-eager 53.js
***
Targeting SpiderMonkey / Gecko (trunk).
Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at dist/include/js/HeapAPI.h

Other variants seem to crash at memory addresses.

Setting [fuzzblocker] because these happen often and s-s because of the unpredictability of the symptoms.

My configure flags are:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --disable-tests --with-ccache --enable-threadsafe <other NSPR options>

=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140317102729" and the hash "c9f1ddebc404".
The "bad" changeset has the timestamp "20140317104729" and the hash "ce6a8fa5db7d".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c9f1ddebc404&tochange=ce6a8fa5db7d

Brian, only bug 979480 is in the regression window. Is it a likely regressor?
Flags: needinfo?(bhackett1024)
Attached patch patchSplinter Review
When creating small array buffers the space used for the buffer's inline storage was also accidentally being used for extra fixed slots on the buffer which could be used by newly added properties.

The fix just special cases ArrayBufferObjects in the object initialization code, which is a reasonable but maybe not the most elegant fix.  Since typed arrays will be wanting to do this same thing too pretty soon (for lazily constructed array buffer objects) we'll need a more general mechanism, but that can wait.
Assignee: nobody → bhackett1024
Attachment #8392904 - Flags: review?(sphink)
Flags: needinfo?(bhackett1024)
The same memory being used for two different things sounds bad.
Comment on attachment 8392904 [details] [diff] [review]
patch

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

Oops! Sorry for missing that.

::: js/src/jsobj.cpp
@@ +1258,5 @@
> +    // cover the class reservd slots, so that the remaining space in the
> +    // object's allocation is available for the buffer's data.
> +    size_t nfixed;
> +    if (clasp == &ArrayBufferObject::class_) {
> +        JS_STATIC_ASSERT(ArrayBufferObject::RESERVED_SLOTS == 4);

Could this be weakened a little? I wouldn't be surprised if we needed to add more. JS_ASSERT(ArrayBufferObject::RESERVED_SLOTS <= JSCLASS_RESERVED_SLOTS(clasp)). Though a static assertion would be nicer.

I also need to remember this for bug 945152, which I'm thinking might want to create an ArrayBufferObject subclass with more slots.
Attachment #8392904 - Flags: review?(sphink) → review+
I left the assertion alone, as it is already guarded on a test for ArrayBufferObject::class_ and will need to be modified for ABO subclasses (as well as typed arrays).

https://hg.mozilla.org/integration/mozilla-inbound/rev/abcc4bcd5baa
landed on central https://hg.mozilla.org/mozilla-central/rev/abcc4bcd5baa
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Group: javascript-core-security → core-security
JSBugMon: This bug has been automatically verified fixed on Fx31
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.