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

Status: RESOLVED DUPLICATE of bug 634444

(Core :: General, defect)

Description

[Tony Mechelynck [:tonymec]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm... can't reproduce so so far in a recentish debug build (on Mac, though).

Comment 2

[Tony Mechelynck [:tonymec]]

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...

Comment 3

[Tony Mechelynck [:tonymec]]

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.

Comment 4

[Scoobidiver (away)]

I can't reproduce in Firefox/15.0a1 on Windows, whatever the plugins.click_to_play value.

Try with a new profile.

Comment 5

[Tony Mechelynck [:tonymec]]

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.

Comment 6

[Tony Mechelynck [:tonymec]]

Attachment: clipboard dump of about:support in the profile where I see the bug

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.

Comment 7

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

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]

Comment 8

[Tony Mechelynck [:tonymec]]

(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.

Comment 9

[Nicholas Nethercote [inactive]]

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.

Comment 10

[Tony Mechelynck [:tonymec]]

(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

Comment 11

[Tony Mechelynck [:tonymec]]

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.