Closed Bug 455547 Opened 14 years ago Closed 14 years ago

TM: SCUMM interpreter (canvas + JS demo) crashes with JIT enabled


(Core :: JavaScript Engine, defect, P2)






(Reporter: bugs, Assigned: dvander)




(Keywords: crash, verified1.9.1)


(1 file)

Demo of SCUMM interpreter in JS/canvas - crashes with JIT, works with JIT disabled.
Oh. And retested with latest nightly trunk build to verify it was still crashing.
Report ID: a7855c35-8414-11dd-be3d-001a4bd43e5c
Version: unspecified → Trunk
Aaand a better title.  Sorry.  Sloppy reporting.
Of course, if this is like other JIT bugs, it'll be fixed in a day or two and I'll just close it anyway.
Summary: Crashes with JIT enabled → SCUMM interpreter (canvas + JS demo) crashes with JIT enabled
Summary: SCUMM interpreter (canvas + JS demo) crashes with JIT enabled → TM: SCUMM interpreter (canvas + JS demo) crashes with JIT enabled
This test creates a LOT of traces (maybe because of the interpreter dispatch). We seem to run into a known issue with the JIT being out of code pages. We will work on that bug and see whether this improves subsequently.
Assignee: general → danderson
Flags: blocking1.9.1?
Adding jimb. This also looks like a really hard case to debug. We seem to consume a ton of time running jit code. It doesn't crash for me any more though.
I can confirm that the site loads and no crash using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081007 Minefield/3.1b1pre 20081007033730
re: comment #5 - did you have JIT enabled for content?
Still crashes for me. Updated to nightly on windows and OSX, a few minutes ago, loaded URL, crashed.
Expanding platform as a result.

OS: Windows XP → All
Hardware: PC → All
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081008 Minefield/3.1b2pre

- No crash but 100% CPU usage (run for about 5 mins)
- How long did you leave it running before it crashed?
I looked at this a bit a while ago. We have 2 issues: we generate way to many traces (underlying code is a very branchy interpreter, we perform way too much tail duplication, we have to limit tree growth here). Eventually this triggers a 2nd bug where we don't GC the code cache properly. The latter is being worked on atm since is sensitive, the form I will try to look into pretty soon. Just a heads up.
Re: comment #7  - it crashes instantly when you press the start button.
the 100% CPU usage I have not yet been able to reproduce, but I left it running for, as noted, 5 minutes.
I then killed it off.

And, while I'm at it.  Thanks Andreas for keeping the avg user informed of your progress :).
... Start button was a reference to bug #458227.
Getting these two mixed up.  For all I know, one is a dupe of the other, internally.
Severity: normal → critical
Keywords: crash
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1b2
Attached patch proposed fixSplinter Review
Problem is we record infinitely many traces since demotions were against the branch frag's IP and not the root frag's.  Crash is maybe from release builds where we'd hit the code cache limit much faster?
Attachment #344678 - Flags: review?(gal)
Attachment #344678 - Flags: review?(gal) → review+
Closed: 14 years ago
Resolution: --- → FIXED
please set back to RESOLVED FIXED after landing in mozilla-central.  Thanks.
Resolution: FIXED → ---
This landed in mozilla-central a while ago.
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Flags: in-litmus-
Seeing as there hasn't been any discussions about this bug for 4 1/2 months, I'm
guessing there aren't any residual issues. I'm moving this to verified as a
result. If anyone has any qualms, feel free to bring them up.
You need to log in before you can comment on or make changes to this bug.