832377 - CPU-intensive script freezes or even crashes Firefox

Status: RESOLVED DUPLICATE of bug 516518

(Core :: JavaScript Engine, defect)

Description

[cousteau]

Firefox GUI seems to freeze when I run CPU-intensive scripts.

Example JavaScript URL:  javascript:c=0;for(i=0;i<10e6;i++)c+=Math.random();c

Result:  browser GUI freezes and doesn't display signs of interaction with buttons, tabs, menus or text selection.

System:
* Xubuntu 12.04 64b
* Firefox 18.0 from Ubuntu repositories
* Intel Core i5 4x 3.30 GHz
* 3.8 GB RAM  (no idea what happened to the 0.2 remaining ones)
* NVidia graphics card GeForce GT 420 (1 GB RAM) + driver from repositories (nvidia-experimental-304)

As suggested on IRC, I tested with a new profile and the nightly build (firefox-21.0a1.en-US.linux-x86_64.tar.bz2).
New result:  the browser crashes.  Command line output:  *** Compartment mismatch 0x7fc375bf0000 vs. 0x7fc37679e800

Comment 1

[Scoobidiver (away)]

Please provide a testcase as an attachment and a stack trace or crash ID from about:crashes.

Comment 2

[Matthias Versen [:Matti]]

The freeze is "normal" while the script runs due to the single Process.
I get 5000133.10464928 as result with 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130118 Firefox/21.0
Build: 20130118193510

Do you have a crash ID from about:crashes ?

mid-air: 
Scoobidiver: The provided testcase works, put it in the URL bar as example

Comment 3

[Scoobidiver (away)]

Here is my crash report on Windows: bp-3c3a9eb0-0444-45f4-b156-51d5e2130118

Comment 4

[Andrew McCreight [:mccr8]]

Ah, yes, this is the same problem as bug 832435.  Many kinds of javascript: things in the URL bar will crash.

Comment 5

[Andrew McCreight [:mccr8]]

Oh, right, the original problem is different, so let's just keep this about that. The crash is a very recent regression in Nightly, and unlikely to be related to the original problem.

Comment 6

[Andrew McCreight [:mccr8]]

Maybe the problem here is that the slow script dialog isn't triggering for javascript: URLs?

Comment 7

[cousteau]

Well, I would expect the rest of the browser (GUI, other tabs, page rendering...) not to freeze while there's a script running, so even if there's a CPU-hogging script running this doesn't mean Firefox stops working until it finishes or the slow script dialog is open, and I can still use Firefox while the function finishes.

Comment 8

[Matthias Versen [:Matti]]

a) A script can always freeze Firefox since it's single process.
b) There is a slow script warning that should allow you to stop the script after some time. It's quite possible that this isn't triggered for JS entered in the URL bar because such scripts are running AFAIK with Chrome privileges.

What is now your issue. a) or b)

Comment 9

[Boris Zbarsky [:bzbarsky]]

1)  Scripts entered via the url bar don't run with chrome privileges.

2)  Even chrome-privileged scripts have a timeout on them.

The operation callback should really be running in this case.  If it's not, that's a JS engine bug.

Comment 10

[cousteau]

My problem is (a): scripts shouldn't freeze Firefox but run on a separate thread. Otherwise, loading pages with intensive scripts make Firefox look slow, worsening the user experience (even if after a while the javascript process is interrupted and the user is asked for feedback). So this would be an "enhancement" rather than a bug report, now that I know that this was the expected behavior.

About the crash on the beta, well, that's actually a bug, but should be treated separately since it was not the reason for this report.

Comment 11

[Scoobidiver (away)]

(In reply to cousteau from comment #10)
> My problem is (a): scripts shouldn't freeze Firefox but run on a separate
> thread.
First, as a user, you are not able to choose the right solution to a problem.
Then, the multi-process management is a long-standing issue and was part of Electrolysis (https://wiki.mozilla.org/Electrolysis) that was stopped because it requires to rewrite entirely the code. As a consequence, no new Firefox or HTLM5 features would be integrated into Firefox during several years and many developers would have stopped working for Mozilla.
There are two alternative on-going projects:
https://wiki.mozilla.org/Performance/Snappy
https://wiki.mozilla.org/Performance/MemShrink

> About the crash on the beta, well, that's actually a bug
and it will stay like that.

Comment 13

[cousteau]

(In reply to Scoobidiver from comment #11)
> First, as a user, you are not able to choose the right solution to a problem.
Ok, let's consider this a suggestion/enhancement rather than a bug, then.

If implementing JavaScript as an actual thread is not an option (at least for now), couldn't Firefox at least be modified so that it periodically pauses the JavaScript execution (say, every 50 ms) and checks if there are pending actions/events to be attended for the UI and web content, in a similar way that it pauses it after 20 seconds to ask the user whether to stop the script execution or not?  In other words, artificially implement multitasking without using threads.

Should I leave this bug and open a new one (or look for an already existing one) for this kind of suggestions?  (This is probably related to the Snappy project, if I understand correctly)