Closed Bug 476560 Opened 11 years ago Closed 11 years ago

Nanojit assembler isn't always properly initialized on entry to beginAssembly

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: dmandelin, Assigned: dmandelin)

References

Details

(Keywords: fixed1.9.1)

Attachments

(1 file)

Attached patch PatchSplinter Review
I believe this bug is the cause of the newly reported crasher in bug 465773. That bug is null pointer deref that corresponds to an assertion failure and also the register consistency check. 

Playing around with that test case, I was able to show that the register state could be invalid upon entry to beginAssembly. It appears that by design endAssembly does the state reset, but the state reset is bypassed on error paths.

This patch simply adds another reset on entry to beginAssembly. Given the delicacy of the state invariants, I'd prefer to reset too much rather than trying to do it just enough.

This patch has no SS perf impact.
Attachment #360216 - Flags: review?(gal)
I checked into the cause more closely per Andreas's request. It turned out to be a little trickier than I thought, but it does appear to be what I claimed in comment 0. It happens in this order:

  leave endAssembly by early return (thus skipping reset)
  start assembling the next trace
  fail consistency check at header of assemble

In retrospect, it makes sense that the register state is still OK at the early return. But then it appears to get scrambled by the next call to genEpilogue (via beginAssembly), and is in a bad state by the time the next assemble is called.
Attachment #360216 - Flags: review?(gal) → review+
Pushed as 3520442a9ec3 and merge changeset dd51548c5ebd.
http://hg.mozilla.org/mozilla-central/rev/3520442a9ec3
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.