Closed Bug 647991 Opened 9 years ago Closed 9 years ago

TI+JM: Assertion failure: Call site vanished., at ../methodjit/Retcon.cpp:112


(Core :: JavaScript Engine, defect)

Not set





(Reporter: jandem, Unassigned)


(Blocks 1 open bug)



(1 file)

207 bytes, application/x-javascript
[""][NaN] = 2;
-([][[""][String] = ""] = null);

This obscure snippet fails with -m -n -a at revision 7928f2dc3d4d:

$ ./js -m -n -a test.js
Assertion failure: Call site vanished., at ../methodjit/Retcon.cpp:112
The first times we go through the SETELEM assigning null, we go through an inline stub call and forget the SETELEM is pushing a constant 'null'.  Then when recompiling from the Neg we make the SETELEM stub call OOL and get the constant pushed value which we fold in the Neg.

This could be fixed by remembering the constant across the inline stub call, but I think it's easier and simpler to bite the bullet and allow all constants and copies to be unstable across compilations.  This would free the compiler to make any decision it wants wrt pushing constants and syncing based on the input types, and would require us to emit OOL rejoin paths when folding constants (not a big deal).  (additionally, I don't think the pushed singletons are stable across compilations, we just haven't found a fuzz test exposing the problem).

Will fix.
Attached file Another testcase
Here's another test case. It fails to rejoin after a recompilation triggered by Math.floor(-0).
Blocks: 648502
This splits things out so that we don't rejoin at arbitrary call sites but at rejoin sites that have been added to the code, adjust var/stack double types as necessary and jump to the right place.  Normal use is with the REJOIN_SITE or REJOIN_SITE_ANY macros, which define structures that generate the rejoin sites when they are destroyed --- after the fast/stub paths for the op have been generated, and regardless of the path taken through the op.
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.