Well, 9 is finally up and running after some difficulty with the initial build. However, it's also having some real trouble being stable -- it crashes with only minimal use and I strongly suspect the new garbage collector. However, part of the plugin IPC stack also appears in affected backtraces (yes, with plugins off). I'm trying to debug this, but it's failing in subtle and unrepeatable ways.
If I am unable to solve the stability issue by next week, we will issue an 8.0.2 beta with the new features scheduled for 9 and decide what to do at that point. The ESR is not far away (Mozilla's extended service release, to replace 3.6), so that could give us an out. More soon.
The following link causes TenFourFox to lock up and then crash after a few seconds of the beach ball:
ReplyDeletehttp://hypervocal.com/news/2011/supernanny-state-200-pound-ohio-boy-taken-from-family-placed-into-foster-care/
I'm using the latest version of the 7450 build.
Happens on iBook G4 TFF 8.0 7450 just as described.
ReplyDeleteLooks like issue 37 resp. 85. No crash if JS or tracejit is disabled.
ReplyDeleteYup, it's stack. Issue 113. I'm rather upset that 256MB is still not enough for some sites.
ReplyDeleteI'm not sure if methodjit will make this worse or better. Making a reasonable guess, I think our next step is 384MB. Soon TenFourFox will be all stack and no browser. :-/
Bloody hell, what on earth is that site running? I had to run it up to a full gigabyte of stack to get it to stick. By the way, that is as high as we go in 32-bit; the stack pointer is all the way up at 0xf0000000.
ReplyDeleteClassic, try it in FF 3.6. They report unresponsive script with option to stop it & no crash. Can't TFF do the same?
ReplyDeleteYes (and we're talking about that in issue 114, because 1GB of stack is as high as we go with the application as currently engineered). However, the JIT magnifies this problem somewhat in that it makes it possible for the Mac to actually run the script; we just run out of stack. More to the point, we *do* want to be able to run such sucky scripts to completion if the user must; the whole point is to have a modern browser. I'm going to talk about this more in the 9b1 announcement, which should be today or tomorrow (the G5 is chugging out the final beta builds).
ReplyDeleteThis script never runs to completion on FF 8 on my macBook. Load wheel keeps spinning with no crash. Stop load button stops the load.
ReplyDeleteThe load wheel doesn't necessarily mean the script is or isn't still running. Open loads for other reasons will continue to spin it even if scripts have finished. (FTR, the page did eventually fully load on my quad G5 with 9b1. It took it almost two minutes, but it did finish. That said, I don't think anyone here is arguing that the stuff they're loading is an absolute mess.)
ReplyDeleteYep! Crash is bad though sacrificing a Gig of stack to prevent it is a little tough to take.
ReplyDeleteWhen methodjit arrives, would it be possible to compile in stack check at the beginning of every function?
ReplyDeleteThe function prologue clearly knows where the stack pointer is. What we don't know is how to have it flag the browser that the tracer (or JIT in general) should abort, or if there even is such a mechanism. I wouldn't want to explore this until we have a disposition on methodjit.
ReplyDelete>if there even is such a mechanism
ReplyDeleteThere most definitely is, as JIT makes assumptions which could later turn out to be wrong.
Yes, but those don't necessarily interrupt execution. We need a way to raise an exception that gets all the way up into the DOM JS environment for the browser. If you know of something like that, please talk about it in issue 114.
ReplyDeleteThis would have been my next question, too, after the ideas in issues 133/114: Why can't we just tell if the stack grows to 255.9 MB and stop the tracejit at that point (I'd only have asked in a less technical way). Okay, question answered.
ReplyDeleteHey! The fat kid page works in TFF 9! WTF?
ReplyDeleteYes, spiking at >500 MB of real memory :-O
ReplyDelete