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.
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.
JSBugMon: The testcase found in this bug no longer reproduces (tried revision fe58c6671ebd).
This is very likely a memory corruption, marking s-s until resolved.
Bisect points to a merge here, unlikely that it fixed this issue. Someone needs to investigate this on the original revision.
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.
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.
Testcase is too complex to add.