Closed Bug 756150 Opened 8 years ago Closed 8 years ago
.options .strict set to true
51.28 KB, text/plain
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.
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.