Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 722260 - Assertion failure: a.asBits == b.asBits, at js/src/builtin/MapObject.cpp:99
: Assertion failure: a.asBits == b.asBits, at js/src/builtin/MapObject.cpp:99
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla13
Assigned To: Jeff Walden [:Waldo] (remove +bmo to email)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz
  Show dependency treegraph
Reported: 2012-01-30 03:06 PST by Christian Holler (:decoder)
Modified: 2013-01-19 14:22 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch with tests (5.27 KB, patch)
2012-01-31 10:42 PST, Jeff Walden [:Waldo] (remove +bmo to email)
luke: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2012-01-30 03:06:36 PST
The following test asserts on mozilla-central revision 8a59519e137e (options -m -n):

var m = new Map;
var key = -((/\u0024/ ).x);
var v = {};
Comment 1 Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-30 15:19:12 PST
  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).
Comment 2 Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-31 10:42:53 PST
Created attachment 593157 [details] [diff] [review]
Patch with tests
Comment 3 Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-31 16:20:43 PST

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.
Comment 4 Matt Brubeck (:mbrubeck) 2012-01-31 17:36:21 PST
Sorry, had to back this out on inbound because it (or something it landed with) had some jsreftest issues:
Comment 5 Jeff Walden [:Waldo] (remove +bmo to email) 2012-02-01 11:21:11 PST

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/, 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.
Comment 6 Ed Morley [:emorley] 2012-02-02 07:23:12 PST
Comment 7 Christian Holler (:decoder) 2013-01-19 14:22:19 PST
Automatically extracted testcase for this bug was committed:

Note You need to log in before you can comment on or make changes to this bug.