Last Comment Bug 732845 - IonMonkey: Assertion failure: mutationCount == p.mutationCount, at ./dist/include/js/HashTable.h:688
: IonMonkey: Assertion failure: mutationCount == p.mutationCount, at ./dist/inc...
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86_64 Linux
-- major (vote)
: ---
Assigned To: Jan de Mooij [:jandem]
: Jason Orendorff [:jorendorff]
: 738496 (view as bug list)
Depends on:
Blocks: langfuzz IonFuzz
  Show dependency treegraph
Reported: 2012-03-04 17:41 PST by Christian Holler (:decoder)
Modified: 2013-02-05 05:57 PST (History)
6 users (show)
choller: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase for shell (3.12 KB, text/javascript)
2012-03-04 17:41 PST, Christian Holler (:decoder)
no flags Details
Fix (2.65 KB, patch)
2012-05-15 04:41 PDT, Jan de Mooij [:jandem]
dvander: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2012-03-04 17:41:20 PST
Created attachment 602778 [details]
Testcase for shell

The attached testcase asserts on ionmonkey revision 1fd6c40d3852 (run with --ion -n -m --ion-eager), tested on 64 bit.
Comment 1 User image Gary Kwong [:gkw] [:nth10sd] 2012-03-28 14:53:01 PDT
See bug 738496 comment 2 for a reliably small testcase with the same assertion on IonMonkey.
Comment 2 User image Christian Holler (:decoder) 2012-04-03 05:26:08 PDT
Not sure if the test here is still valid, marking for a check. But even if it is not, we should ensure that the cause is the same as e.g. in bug 738496 because it seems like a generic assertion to me that multiple memory corruptions could produce.
Comment 3 User image Christian Holler (:decoder) 2012-04-03 05:27:17 PDT
JSBugMon: The testcase found in this bug no longer reproduces (tried revision fe58c6671ebd).
Comment 4 User image Christian Holler (:decoder) 2012-04-17 11:28:32 PDT
This is very likely a memory corruption, marking s-s until resolved.
Comment 5 User image Christian Holler (:decoder) 2012-04-18 06:33:05 PDT
Bisect points to a merge here, unlikely that it fixed this issue. Someone needs to investigate this on the original revision.
Comment 6 User image Christian Holler (:decoder) 2012-05-13 15:24:37 PDT
Note that I still see this assertion in the fuzzer, but the tests are always very complex and hard to reduce. If this assertion is very generic, then we can compose a new test to analyze to ensure that we're working on the correct issue.
Comment 7 User image Jan de Mooij [:jandem] 2012-05-15 04:32:09 PDT
*** Bug 738496 has been marked as a duplicate of this bug. ***
Comment 8 User image Jan de Mooij [:jandem] 2012-05-15 04:41:02 PDT
Created attachment 623998 [details] [diff] [review]

The bug is that in generateVMWrapper we do this:
VMWrapperMap::AddPtr p = functionWrappers_->lookupForAdd(&f);
if (p)
    return p->value;
// ...
IonCode *wrapper = linker.newCode(cx);
if (!wrapper || !functionWrappers_->add(p, &f, wrapper))
    return NULL;
This is only safe if functionWrappers_ is not modified between the |lookupForAdd| and |add| calls. However, linker.newCode may trigger a last ditch GC and sweep functionWrappers_, so we have to use relookupOrAdd. We do this in some other places for the same reason.
Comment 9 User image Jan de Mooij [:jandem] 2012-05-15 11:27:49 PDT
Comment 10 User image Christian Holler (:decoder) 2013-02-05 05:57:04 PST
Testcase is too complex to add.

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