984766 - 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

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: 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?

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

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.

Comment 3

[Andrew McCreight [:mccr8]]

The same memory being used for two different things sounds bad.

Comment 4

[Steve Fink [:sfink] [:s:]]

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.

Comment 5

[Brian Hackett [Laid off!]]

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

Comment 6

[Carsten Book [:Tomcat]]

landed on central https://hg.mozilla.org/mozilla-central/rev/abcc4bcd5baa

Comment 7

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 8

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed on Fx31