Closed Bug 839215 Opened 7 years ago Closed 7 years ago

Assertion failure: obj->hasSingletonType(), at jstypedarrayinlines.h:245


(Core :: JavaScript Engine, defect, critical)

Not set



Tracking Status
firefox20 --- unaffected
firefox21 --- fixed


(Reporter: decoder, Assigned: terrence)


(Blocks 1 open bug)


(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update,bisect])


(1 file)

The following testcase asserts on mozilla-central revision d55669a02834 (no options required):

var b = new ArrayBuffer(10000000000);
var dv = new DataView(b);
Marked this s-s because the assertion depends on the size of the ArrayBuffer (smaller sizes, e.g. 1000, don't trigger this). I haven't seen a crash or Valgrind error though, so it might still be harmless.
Whiteboard: [jsbugmon:update,bisect]
This is likely caused by the singleton allocation change I made in Bug 706885.
Assignee: general → terrence
Attached patch v0Splinter Review
Looks like I simply inverted the logic here.
Attachment #712991 - Flags: review?(bhackett1024)
Blocks: 706885
Terrence, what sort of security rating is appropriate for this?  Can it cause memory corruption or something else?
Keywords: regression
Thanks for the reminder: I totally forgot to check that before restoring the correct behavior. 

After untangling the logic, the questions are (1) whether calling setSingleton can lead to incorrect behavior in SetInitializerObjectType and (2) is the pre-existing skipping of Monitor in the asserted case correct.  For (1): SetInitializerObjectType handles both cases correctly. For (2): this should be fine -- we are making this TA a singleton because of its size and not for any of the reasons that Monitor observes.

This particular assertion is just there to protect an optimization. It can actually lead to any incorrect behavior, just slowdowns on emscripten compiled programs.
Group: core-security
Attachment #712991 - Flags: review?(bhackett1024) → review+
Flags: in-testsuite+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Depends on: 842482
FYI, the test case refered in comment 0 makes the test fails on tegra boards because they are lacking memory.  Is there a way to work around that?
This was removed from the test suite in Bug 959156 due to OOM problems on the Windows test slaves.
Flags: in-testsuite+ → in-testsuite-
You need to log in before you can comment on or make changes to this bug.