User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: - Disable JavaScript in Firefox 12.0; - Enter de following URL: http://esporte.uol.com.br/futebol/ultimas-noticias/2012/05/31/joel-santana-revela-surpresa-com-novela-ronaldinho-no-fla-e-decreta-acabou.htm Actual results: - Just wait. No need to do anything; - Firefox begins to allocate memory crazily, turns slow, slow, slow and in a few minutes crashes. With JavaScript ENABLED, everything goes "ok" (Firefox opens the page with minimal memory usage and don't crash). Expected results: What should have happened? Firefox should open the page in an ordinary way. I tested in several computers with Windows XP SP3, with 2GB and 3GB of RAM with the same result: Firefox crashes specta­cularly. In 64 bits Windows (I tested in 1 computer only), Firefox turns slow, near unusable but don't crash.

With a new profile and JS disabled, the memory usage is stable in Fx 12.0 and Fx 13.0b7. Does it happen in Safe Mode (see https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)?

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120604030527 I can see similar behavior in Firefox Nightly on Linux. With JS disabled, the memory usage is around 480 MB (does not increase endlessly), with JS enabled, it usually stays under 90 MB. It does happen even in Safe Mode. about:memory says (JS disabled): 479.69 MB (100.0%) -- explicit ├──402.27 MB (83.86%) -- images │ ├──402.23 MB (83.85%) -- content │ │ ├──402.01 MB (83.81%) -- used │ │ │ ├──313.27 MB (65.31%) ── uncompressed-heap │ │ │ ├───88.74 MB (18.50%) ── raw │ │ │ └────0.00 MB (00.00%) ── uncompressed-nonheap │ │ └────0.22 MB (00.05%) ++ unused │ └────0.04 MB (00.01%) ++ chrome ├───30.18 MB (06.29%) -- js │ ├──24.26 MB (05.06%) ++ (121 tiny) │ └───5.92 MB (01.23%) ++ runtime ├───26.95 MB (05.62%) ── heap-unclassified ├───11.02 MB (02.30%) -- window-objects │ ├───8.73 MB (01.82%) -- top(http://esporte.uol.com.br/futebol/ultimas-noticias/2012/05/31/joel-santana-revela-surpresa-com-novela-ronaldinho-no-fla-e-decreta-acabou.htm, id=16)/active/window(http://esporte.uol.com.br/futebol/ultimas-noticias/2012/05/31/joel-santana-revela-surpresa-com-novela-ronaldinho-no-fla-e-decreta-acabou.htm) │ │ ├──5.65 MB (01.18%) ── dom [2] │ │ └──3.08 MB (00.64%) ++ (2 tiny) │ └───2.30 MB (00.48%) ++ (3 tiny) └────9.27 MB (01.93%) ++ (9 tiny) With JS enabled, the images node looks like this: ├────1.55 MB (01.32%) -- images │ ├──1.52 MB (01.29%) -- content │ │ ├──1.52 MB (01.29%) -- used │ │ │ ├──1.41 MB (01.20%) ── raw │ │ │ └──0.11 MB (00.09%) -- (2 tiny) │ │ │ ├──0.11 MB (00.09%) ── uncompressed-heap │ │ │ └──0.00 MB (00.00%) ── uncompressed-nonheap │ │ └──0.00 MB (00.00%) ++ unused │ └──0.04 MB (00.03%) ++ chrome

I am sorry for another post (as I didn't notice this earlier), but it seems the large memory usage is caused by <noscript> elements on the page: Most of 526 <noscript> elements contain an <img> element with a (relatively) large picture.

(In reply to Scoobidiver from comment #1) > With a new profile and JS disabled, the memory usage is stable in Fx 12.0 > and Fx 13.0b7. > Does it happen in Safe Mode (see > https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)? The crash also occurs in safe mode, but not so frequent nor automatic. In safe mode is necessary user interaction to cause a crash. However, the allocation memory nightmare continue. Look in that sequence: a) I had 19 tabs open; b) I disabled JavaScript; c) I add tab 20 and open in that tab the above infamous page (link); d) I quickly reboot Firefox in safe mode; e) Upon Firefox restart, I confirmed safe mode; f) Firefox jump to tab 20 (the last active); g) Firefox begins to allocate memory crazily. It stops in +- 1.7GB. No crash, however; h) I wait several minutes; nothing happens!; i) I try to click another tab. Firefox appears to ignore my click; j) About 3 MINUTES after I have clicked, Firefox change to the tab clicked; k) Firefox memory usage drop to +- 200MB; l) I realize that Firefox is "BLOAT" ("drunk"); m) I go back to the tab 20 (the infamous); n) Firefox memory usage rises immediately to +- 1.7GB; o) Each time that I click in another tab and go back to tab 20 (the infamous), Firefox be more slow ("drunk"); p) After 40 minutes doing this, I finally win: Firefox crashed;

Can you provide the crash ID from about:crashes? Can you attach your about:support page in Normal Mode?

(In reply to Scoobidiver from comment #5) > Can you provide the crash ID from about:crashes? > Can you attach your about:support page in Normal Mode? a) about:crashes: All following crashes were caused by the link above (the infamous) only this month; bp-db94ab8b-be21-486f-aa02-cf9bc2120604 4/6/2012 12:35 (occurred in safe mode) bp-a1c80632-94ca-4313-956c-e95502120604 4/6/2012 10:35 (occurred in safe mode) bp-f3014294-b229-47b4-8eb1-3e5d62120604 4/6/2012 09:56 bp-494f4424-3a17-410b-b66f-57ba32120602 2/6/2012 16:27 bp-4e76c21a-e35e-4a50-b1f8-986162120601 1/6/2012 15:05 bp-5de4936e-7faf-4390-9938-ce0ee2120601 1/6/2012 07:13 bp-923c4f76-19a8-46e1-84ff-d7da52120601 1/6/2012 01:37 bp-31b0662c-904d-4432-9a09-e02192120601 1/6/2012 00:27 bp-4ee76d30-4ea9-4f3b-9dda-3b9772120601 1/6/2012 00:22 bp-4639fcf3-e62b-431e-a8cf-d9ad72120601 1/6/2012 00:13 b) about:support Attached: - support_data.xhtml - aboutSupport.css - aboutSupport.js Please, create a folder named "support_data_arquivos" and place the aboutSupport.css and aboutSupport.js to the page display properly. You can also do something more easy: load this problematic page in any Windows XP SP3 around you. I submitted this page to NoScript team that reproduced this crash in a Windows XP SP3 computer in a few minutes.

The signature is empty. Can you provide a valid stacktrace using a debugger (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg)?

(In reply to Scoobidiver from comment #10) > The signature is empty. > Can you provide a valid stacktrace using a debugger (see > https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg)? This bug is very easy to reproduce in any computer with Windows XP SP3. You, that own much more knowledge that me, can't do this?

I am a volunteer with a Windows 7 computer, so it works for me.

(In reply to Scoobidiver from comment #12) > I am a volunteer with a Windows 7 computer, so it works for me. Pages like this causes high memory allocation in *ANY* computer and OS. In 32 bits OS's like Windows XP, Firefox crashes due virtual address space exhaustion. Bugzilla is full of complaints that even in computers with 8GB of RAM, Firefox becomes "BLOAT" with pages with a lot of pictures. You are a volunteer and I'm only a USER. I dedicated I time and knowledge that I don't have to help solve a problem of Mozilla's responsibility. There is a terrible project's flaw in the form that Firefox deal with images. I start to see SHADOWS in the Firefox future! Please, close this bug report and thank you for your patience.

grr, I lost my whole comment due to mid-air The crash is a OOM due to the 32bit process limit and the empty stack confirms that. Disabling the image loading fixes this and confirms the about:memory post from the reporter

Reporter: Reports from other cases where images are involved are absolutely irrelevant unless you find technical similarities.High memory usage alone is not enough. Your "bloat" part of your comment therefore doesn't belong into this report. Back to the bug and my lost comment: I can reproduce this with Firefox12 on Windows7/32. A fresh started Firefox is at 1GB in 1 minute. Opera seems to also "leak" memory but much slower (100MB after >1 minute). I'm now looking for an image that is causing this. Probably a mjepg image from an ad network. Hitting ESC on that page stops the memory climbing.

(In reply to Matthias Versen (Matti) from comment #15) > Reporter: Reports from other cases where images are involved are absolutely > irrelevant unless you find technical similarities.High memory usage alone is > not enough. Your "bloat" part of your comment therefore doesn't belong into > this report. > > Back to the bug and my lost comment: > I can reproduce this with Firefox12 on Windows7/32. A fresh started Firefox > is at 1GB in 1 minute. Opera seems to also "leak" memory but much slower > (100MB after >1 minute). > > I'm now looking for an image that is causing this. Probably a mjepg image > from an ad network. Hitting ESC on that page stops the memory climbing. Dear Matthias, thank you by your attention. Finally someone can hear-me. My friends of NoScript succesfully reproduced this bug and filed this bug report to Mozilla: Crash, 0d68ec07-07af-4dd0-a6cb-7159d2120601. Related, Bug 760952 - crash in nsLineLayout::ReflowFrame. Maybe this can help! Thanks!

This page seems to preload many images if you disable JS. This is just broken. Many of those images are over 500kb with a dimension of 1920x1080 Example: http://e.imguol.com/esporte/futebol/2012/02/14/joel-santana-conversa-com-ronaldinho-e-deivid-durante-treino-do-flamengo-na-argentina-14022012-1329235043015_615x300.jpg Are we decoding the images in the background and could we avoid that ? marking new but I expect that this is a dupe

It looks like the images in question are styled display:none, so I don't think there's any reason why we need to be decoding them. At a glance other browsers don't appear to decode in this case.

Several pages of this site appear to behave similarly. Another link to test with JS disabled. It seems that with this page the crash is faster. http://esporte.uol.com.br/futebol/campeonatos/brasileiro/serie-a/ultimas-noticias/2012/07/31/atletico-mg-blinda-ronaldinho-gaucho-e-o-proibe-de-dar-entrevistas-antes-do-jogo-com-flamengo.htm

Over to :tn; jet says he has a local patch in progress.

I wanted a fresh empty bug so I posted the wip patches to bug 784591.

Can we just forward-dupe this, then?