Closed Bug 839215 Opened 7 years ago Closed 7 years ago
Assertion failure: obj->has
Singleton Type(), at jstypedarrayinlines .h:245
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.
This is likely caused by the singleton allocation change I made in Bug 706885.
Assignee: general → terrence
Looks like I simply inverted the logic here.
Attachment #712991 - Flags: review?(bhackett1024)
Terrence, what sort of security rating is appropriate for this? Can it cause memory corruption or something else?
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.
Attachment #712991 - Flags: review?(bhackett1024) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
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.