Closed Bug 1314175 Opened 7 years ago Closed 6 years ago

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


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox52 --- affected


(Reporter: gkw, Unassigned)



(6 keywords, Whiteboard: [fuzzblocker] [jsbugmon:])


(1 file)

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;


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)

For detailed crash information, see attachment.

Setting s-s because TypedArrays are seemingly involved and the testcase crashes at a weird memory address.
=== 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:

Andre/Waldo, is bug 1121938 a likely regressor?
Blocks: 1121938
Flags: needinfo?(jwalden+bmo)
Flags: needinfo?(andrebargull)
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.
Flags: needinfo?(andrebargull)
=== 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:

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.
Flags: needinfo?(jwalden+bmo) → needinfo?(jdemooij)
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.
NI smvv, since this is likely similar to bug 1313807.
Flags: needinfo?(jdemooij) → needinfo?(sandervv)
Upgrading to [fuzzblocker] because there are crashes at various instructions with nothing on the stack making it difficult to ignore.
Whiteboard: [jsbugmon:update] → [fuzzblocker][jsbugmon:update]
Whiteboard: [fuzzblocker][jsbugmon:update] → [fuzzblocker] [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision a69583d2dbc6).
Whiteboard: [fuzzblocker] [jsbugmon:update,ignore] → [fuzzblocker] [jsbugmon:bisectfix]
Whiteboard: [fuzzblocker] [jsbugmon:bisectfix] → [fuzzblocker] [jsbugmon:]
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
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.
Yes this was fixed by bug 1313807.
Closed: 6 years ago
Flags: needinfo?(sandervv)
Resolution: --- → DUPLICATE
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.