Closed Bug 761113 Opened 8 years ago Closed 8 years ago
Page with hundreds of large display:none styled images causes causes high memory usage and OOM
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  │ │ └──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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
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
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
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
Status: UNCONFIRMED → NEW
Component: Untriaged → ImageLib
Ever confirmed: true
Product: Firefox → Core
QA Contact: untriaged → imagelib
Summary: Firefox 12.0 crashes in Windows XP SP3 with JS DISABLED. → Firefox 12.0 crashes on Windows x86 with JS disabled
Severity: normal → critical
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.
Summary: Firefox 12.0 crashes on Windows x86 with JS disabled → Page with hundreds of large display:none styled images causes causes high memory usage and OOM
Whiteboard: [dupeme?] → [MemShrink]
Attachment #629818 - Attachment mime type: application/octet-stream → application/xhtml+xml
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.
Assignee: nobody → tnikkel
Whiteboard: [MemShrink] → [MemShrink:P2]
I wanted a fresh empty bug so I posted the wip patches to bug 784591.
Can we just forward-dupe this, then?
Status: NEW → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 784591
You need to log in before you can comment on or make changes to this bug.