Closed Bug 756150 Opened 8 years ago Closed 8 years ago

Browser gobbles up all memory until it crashes with javascript.options.strict set to true

Categories

(Core :: General, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 634444

People

(Reporter: tonymec, Unassigned)

References

()

Details

(Keywords: crash, memory-footprint, Whiteboard: [seamonkey2.12-affected])

Attachments

(1 file)

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1 ID:20120517003032

When I try to open the following link in a new tab:
http://www.medpagetoday.com/Cardiology/Arrhythmias/32725
SeaMonkey gobbles up all memory (starting at about 1.5G of 3G RAM, almost all free of 6G swap) until both RAM and swap are all used up and it gets killed. No crash report.

FWIW, I have plugins.click_to_play set to true, which is not the default on SeaMonkey. Javascript is enabled.

This link was found on Josh "timeless" Soref's Facebook timeline; asked if he thought if it was a Gecko bug or a MedPageToday bug, he answered: “Gecko. It should be aware of memory and behave better, try tagging @boris”

I'm not sure in which component this bug belongs, please move as necessary.
Hmm... can't reproduce so so far in a recentish debug build (on Mac, though).
I just tried it again, and saw it again. The page renders, but the progress bar (near bottom right, on the status bar) doesn't go away, and then the HDD starts sawing about. Everything then becomes extremely unresponsive.

I've just restarted into safe mode, let's see if it makes any difference...
No difference in safe mode. One thing I hadn't noticed in «unsafe» mode is that I get requests for cookies, one on a different (tracking?) site, which I deny, the other on medpagetoday, but too late for me to make a choice: it's already swapping like hell.

Ctrl+Alt+F1 (to /dev/tty1, previously logged-in as root) followed by "killall -v seamonkey" works, albeit slowly: after killall displayed the PID of the killed process, Ctrl+Alt+F7 lets me for a brief instant see the cookie popup and the browser window.
I can't reproduce in Firefox/15.0a1 on Windows, whatever the plugins.click_to_play value.

Try with a new profile.
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120517030523

Can't reproduce it either in this build, with a "reasonably new" (but not totally virgin) profile. Not logged-in to Facebook, Google, etc. (don't know if makes a difference).

Next experiment will be a fresh profile in SeaMonkey.
Same build as in comment #0 in a new (freshly created) profile: no significant memory increase, but status bar keeps saying "Transferring data from l.collective-media.net (with something, maybe "Done", repeatedly showing up for a fraction of a second at a time, but too shortly to be really read).

This attachment was obtained by "Copy all to clipboard" in about:support in the profile where I see the bug. *DO NOT* load the multitab homepage (212 tabs), it wasn't loaded at time of failure. Only 15 tabs were open including 3 Google Groups, 3 Facebook pages incl. my Profile and Wall, this bug, about: about:config about:support about:addons about:downloads, etc.

Since I see the bug even in safe mode (comment #3) I don't expect an extension to be the cause.
Tony, do you have "javascript.options.strict" set to "true" in the profile where you can reproduce this issue?  I experienced similar symptoms and tracked it down to that [bug 751402]
Summary: When I try to open this link in a new tab, browser gobbles up all memory until it gets gilled. No crash report. → Browser gobbles up all memory until it crashes with javascript.options.strict set to true
(In reply to Tim Abraldes from comment #7)
> Tony, do you have "javascript.options.strict" set to "true" in the profile
> where you can reproduce this issue?  I experienced similar symptoms and
> tracked it down to that [bug 751402]

Yes I do. Bug 751402 is a dupe by now… of bug 634444. I don't have Firebug installed though, and I see the bug even without opening the Error Console. I'm going to toggle that pref to false for the time being.
Keywords: footprint
A fix for bug 634444 landed on mozilla-central two days ago.  I don't know how patches on mozilla-central migrate to SeaMonkey, but hopefully when the patch does migrate this will be fixed.
(In reply to Nicholas Nethercote [:njn] from comment #9)
> A fix for bug 634444 landed on mozilla-central two days ago.  I don't know
> how patches on mozilla-central migrate to SeaMonkey, but hopefully when the
> patch does migrate this will be fixed.

If they are in common code (Core, Toolkit, etc.), they are taken up in the next compile, as the SeaMonkey client.py pulls the latest mozilla-central as folder mozilla/ inside the comm-central clone.

Fixes in forked code (which IIUC is not the case here) require a port.

Two days ago, you say? Then I'll toggle the pref to true (cf. comment #7) and see if the bug still happens. I'm currently running an hourly build dated after bug 634444 comment #46:

Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0a1 SeaMonkey/2.13a1 ID:20120614022149
No "infinite" gobbling up memory, but I got a crash in libxul. Breakpad came up but doesn't know where to look for symbols for this hourly (I have downloaded the crashreporter-symbols.zip but I don't know how to use it). I don't think it's the same problem since (a) this bug was not for a Breakpad crash, and (b) no crash *or* memory fillup on restart-from-crash though the problematic page did load.

I'll retry with the next nightly so that (if it crashes again) I get libxul symbols.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 634444
You need to log in before you can comment on or make changes to this bug.