1314175 - Crash at a weird memory address or Assertion failure: nbytes > 0, at js/src/gc/Nursery.cpp:365

Status: RESOLVED DUPLICATE of bug 1313807

(Core :: JavaScript Engine, defect)

Description

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

The following testcase crashes on mozilla-central revision 8c9eed5227f8 (build with --enable-debug --enable-more-deterministic --32, run with --fuzzing-safe --no-threads --ion-eager):

function f(x) {
    new Uint16Array(x) + 0;
}
f(0);
f(2147483647);

Backtrace:

0   js-dbg-32-dm-clang-darwin-8c9eed5227f8	0x00b79bb8 js::Nursery::allocateBuffer(JSObject*, unsigned long) + 200 (Nursery.cpp:365)
1   js-dbg-32-dm-clang-darwin-8c9eed5227f8	0x004ae898 AllocateObjectBufferWithInit(JSContext*, js::TypedArrayObject*, int) + 312 (MacroAssembler.cpp:1066)
2   ???                           	0x01f5750b 0 + 32863499
3   js-dbg-32-dm-clang-darwin-8c9eed5227f8	0x00366333 js::jit::IonCannon(JSContext*, js::RunState&) + 819 (Ion.cpp:2846)
4   js-dbg-32-dm-clang-darwin-8c9eed5227f8	0x008abe4d js::RunScript(JSContext*, js::RunState&) + 333 (Interpreter.cpp:384)
/snip

For detailed crash information, see attachment.

Setting s-s because TypedArrays are seemingly involved and the testcase crashes at a weird memory address.

Comment 1

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

Attachment: Detailed Crash Information

Comment 2

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

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

The "good" changeset has the timestamp "20160830082723" and the hash "1a6361b000fcb97f941e4091001e88be0e46927f".
The "bad" changeset has the timestamp "20160830085122" and the hash "633c05b48792f4d55a13e43ad12034a53006797d".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1a6361b000fcb97f941e4091001e88be0e46927f&tochange=633c05b48792f4d55a13e43ad12034a53006797d

Andre/Waldo, is bug 1121938 a likely regressor?

Comment 3

[André Bargull [:anba]]

The assertion failure was still reproducible for me even when I undid all changes from bug 1121938 one by one. So I'm not sure that bug 1121938 has caused this failure.

Comment 4

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

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

The "good" changeset has the timestamp "20160805000432" and the hash "505e6acd9c291504700a57ddf7e88f704f65da46".
The "bad" changeset has the timestamp "20160805000922" and the hash "52a0d2d7639717858ce6868c19a37b95e7039736".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=505e6acd9c291504700a57ddf7e88f704f65da46&tochange=52a0d2d7639717858ce6868c19a37b95e7039736

The bisection window in comment 2 was via 32-bit opt builds, so here's another bisection window using 32-bit debug builds instead.

Jan, is this a likely dupe of bug 1313807? fwiw, the testcase there does not crash 32-bit opt builds, but the one here does, so you might want to add both testcases to the testsuite.

Comment 5

[André Bargull [:anba]]

FWIW I think bug 1121938 only showed up in the initial regression range because of the trailing `+ 0`. `someTypedArray + 0` leads to calling the %TypedArray%.prototype.toString method which was introduced in bug 1121938.

Comment 6

[Jan de Mooij [:jandem]]

NI smvv, since this is likely similar to bug 1313807.

Comment 7

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

Upgrading to [fuzzblocker] because there are crashes at various instructions with nothing on the stack making it difficult to ignore.

Comment 8

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision a69583d2dbc6).

Comment 9

[Fuzzing Team]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/6194aa03e1ad
user:        Jan de Mooij
date:        Tue Nov 29 16:42:28 2016 +0100
summary:     Bug 1313807 - Fix AllocateObjectBufferWithInit to ensure nbytes + sizeof(Value) is valid. r=jwalden

This iteration took 251.198 seconds to run.

Comment 10

[Jan de Mooij [:jandem]]

Yes this was fixed by bug 1313807.