CPU-intensive script freezes or even crashes Firefox

RESOLVED DUPLICATE of bug 516518

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 516518
6 years ago
6 years ago

People

(Reporter: cousteau, Unassigned)

Tracking

({crash, reproducible})

21 Branch
x86_64
Linux
crash, reproducible
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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

6 years ago
Please provide a testcase as an attachment and a stack trace or crash ID from about:crashes.
Severity: normal → critical
Flags: needinfo?(cousteaulecommandant)
Keywords: crash, stackwanted
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
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: stackwanted
Product: Firefox → Core

Comment 3

6 years ago
Here is my crash report on Windows: bp-3c3a9eb0-0444-45f4-b156-51d5e2130118
Blocks: 821733
Status: UNCONFIRMED → NEW
Crash Signature: [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)]
Ever confirmed: true
Flags: needinfo?(cousteaulecommandant)
Keywords: reproducible
Ah, yes, this is the same problem as bug 832435.  Many kinds of javascript: things in the URL bar will crash.
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.
No longer blocks: 821733
Crash Signature: [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)]
Maybe the problem here is that the slow script dialog isn't triggering for javascript: URLs?
(Reporter)

Comment 7

6 years ago
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.
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)
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.
(Reporter)

Comment 10

6 years ago
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

6 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 516518
(Reporter)

Comment 13

6 years ago
(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)
You need to log in before you can comment on or make changes to this bug.