Closed Bug 641225 Opened 15 years ago Closed 15 years ago

TI+JM: Assertion failure: failed to find call site, at ../methodjit/Retcon.cpp:91

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Unassigned)

References

Details

(Whiteboard: fixed-in-jaegermonkey)

Attachments

(2 files, 1 obsolete file)

2.80 KB, text/plain
Details
3.19 KB, application/x-javascript
Details
Attached file Test (obsolete) —
This assert is rare and hard to reduce, I hope you can reproduce. $ ./js -m -n -a test.js Assertion failure: failed to find call site, at ../methodjit/Retcon.cpp:91
Attached file Stack trace —
Hmm, I can't get this to reproduce. How does it look under valgrind? The hard-to-reproduce aspect probably means either uses of uninitialized data or the conservative GC are involved.
Attached file Test 2 —
The original test case does not assert anymore. The new attachment still asserts with -m -a -n at revision 1ce8efbb75cc. Valgrind does not show any messages.
Attachment #518954 - Attachment is obsolete: true
Cool, this asserts for me now.
The recompiler reads each frame's ncode to determine whether it returns into the script being recompiled. The problem is that frames which are evaluated by the interpreter leave this field uninitialized, now that field is NULL'ed out for interpreter frames. http://hg.mozilla.org/projects/jaegermonkey/rev/6dc4e473aa06
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-jaegermonkey
Pushed by clegnitto@mozilla.com: https://hg.mozilla.org/releases/mozilla-release/rev/ba01e1b00f8c [INFER] Compute PC for interpreted frames which failed to compile, bug 641225.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: