The default bug view has changed. See this FAQ.

Assertion failure: a.asBits == b.asBits, at js/src/builtin/MapObject.cpp:99

RESOLVED FIXED in mozilla13

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: decoder, Assigned: Waldo)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
mozilla13
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js-triage-done])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
The following test asserts on mozilla-central revision 8a59519e137e (options -m -n):


var m = new Map;
var key = -((/\u0024/ ).x);
var v = {};
m.set(key,v);
  var key = -((/\u0024/ ).x);

creates a canonical NaN value, then negates it to get the canonical NaN with the sign bit set.  Luke says our value encoding system correctly treats such bit patterns as doubles, so it's not a problem on that account.  This does mean, however, that given a double value generated by script, it's not possible to simply assert that d == JS_CANONICALIZE_NaN(d).
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: js-triage-needed → [js-triage-done]
Created attachment 593157 [details] [diff] [review]
Patch with tests
Attachment #593157 - Flags: review?(luke)

Updated

5 years ago
Attachment #593157 - Flags: review?(luke) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/f3ceed05f6b7

If we're going to have Map and Set on aurora until shortly before merge to beta, it might be worth taking this there, since it seems like something that might easily be stumbled upon.  Not sure about that.  I guess for now I'll default to doing nothing.
Target Milestone: --- → mozilla13
Sorry, had to back this out on inbound because it (or something it landed with) had some jsreftest issues:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a22cb315b248
Target Milestone: mozilla13 → ---
https://hg.mozilla.org/integration/mozilla-inbound/rev/19addd0f1a6d

Aside from the missing-from-the-commit manifests (easy to solve), it turns out that if you add a new directory of JS tests, you have to add the directory to js/src/tests/Makefile.in, else the tests won't be packaged and test machines will complain your tests are missing.  Ugh; I added a comment to js/src/tests/jstests.list to hopefully ward others away from this problem in the future.
https://hg.mozilla.org/mozilla-central/rev/19addd0f1a6d
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
(Reporter)

Comment 7

4 years ago
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.