IonMonkey: Assertion failure: mutationCount == p.mutationCount, at ./dist/include/js/HashTable.h:688

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
major
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: jandem)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Other Branch
x86_64
Linux
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jsbugmon:update,ignore])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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.
See bug 738496 comment 2 for a reliably small testcase with the same assertion on IonMonkey.
(Reporter)

Comment 2

6 years ago
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.
Whiteboard: [jsbugmon:update]
(Reporter)

Comment 3

6 years ago
JSBugMon: The testcase found in this bug no longer reproduces (tried revision fe58c6671ebd).
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
(Reporter)

Comment 4

5 years ago
This is very likely a memory corruption, marking s-s until resolved.
Group: core-security
(Reporter)

Comment 5

5 years ago
Bisect points to a merge here, unlikely that it fixed this issue. Someone needs to investigate this on the original revision.
(Reporter)

Comment 6

5 years ago
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.
(Assignee)

Updated

5 years ago
Assignee: general → jdemooij
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Duplicate of this bug: 738496
(Assignee)

Comment 8

5 years ago
Created attachment 623998 [details] [diff] [review]
Fix

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.
Attachment #623998 - Flags: review?(dvander)
Attachment #623998 - Flags: review?(dvander) → review+
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/projects/ionmonkey/rev/06338317eaba
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Group: core-security
(Reporter)

Comment 10

5 years ago
Testcase is too complex to add.
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.