704680 - Firefox crash on website with lots of images (OOM kill?) [testcase not safe for work]

Status: RESOLVED DUPLICATE of bug 683284

(Firefox :: General, defect)

Description

[Anael Mobilia]

Attachment: Desg log on FF crash

User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111116091359

Steps to reproduce:

A friend reported me than firefox is crashing on a porn website.
A mirror of the site could be find on http://88.191.122.115/ff_crash/SOD.htm .
There are +/- 3000 pictures loaded on the webpage.

I try to open it on safe-mode with FF 8.0.1 and 9.0 beta2, twice FF crash.
My OS is debian 6.0.3


Actual results:

Firefox 8.0 and 9.0 beta2 (runned on safe-mode) crash one time the page is fully charged.

The computer freeze during +/- 30 seconds, during which the HDD is under constant activity, and then FF crashed.
By crash I mean FF window is closed, process is killed. Not a blank / not running window.

I attache a dmesg log : there is many errors reported


Expected results:

The webpage should be displayed.

Comment 1

[Thomas Ahlblom]

Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111122 Firefox/11.0a1

Firefox doesn't crash for me, but my computer starts swapping. I tested with a new clean, profile and right after the page has finished loading says about:memory "1,830.81 MB -- gfx-surface-xlib", but if I press "Minimize memory usage" then I get "0.09 MB -- gfx-surface-xlib".

Attachment 576349 [details] contains rows like:
"[11984.016519] Out of memory: Kill process 4697 (firefox) score 209 or sacrifice child"




Main Process

Explicit Allocations
278.04 MB (100.0%) -- explicit
├──161.30 MB (58.02%) -- images
│  ├──161.27 MB (58.00%) -- content
│  │  ├──161.27 MB (58.00%) -- used
│  │  │  ├──161.27 MB (58.00%) -- raw
│  │  │  └────0.00 MB (00.00%) -- (2 omitted)
│  │  └────0.00 MB (00.00%) -- (1 omitted)
│  └────0.04 MB (00.01%) -- (1 omitted)
├───38.86 MB (13.98%) -- heap-unclassified
├───32.29 MB (11.61%) -- layout
│   ├──30.89 MB (11.11%) -- shell(http://88.191.122.115/ff_crash/SOD.htm)
│   │  ├──27.40 MB (09.86%) -- arenas
│   │  ├───3.35 MB (01.21%) -- textruns
│   │  └───0.14 MB (00.05%) -- (1 omitted)
│   └───1.40 MB (00.50%) -- (5 omitted)
├───22.83 MB (08.21%) -- js
│   ├──10.12 MB (03.64%) -- compartment([System Principal], 0x7f12c3ab5000)
│   │  ├───6.22 MB (02.24%) -- gc-heap
│   │  │   ├──2.78 MB (01.00%) -- objects
│   │  │   │  ├──2.17 MB (00.78%) -- function
│   │  │   │  └──0.61 MB (00.22%) -- (1 omitted)
│   │  │   ├──1.99 MB (00.72%) -- shapes
│   │  │   │  ├──1.79 MB (00.64%) -- tree
│   │  │   │  └──0.21 MB (00.07%) -- (1 omitted)
│   │  │   └──1.44 MB (00.52%) -- (5 omitted)
│   │  ├───2.50 MB (00.90%) -- (7 omitted)
│   │  └───1.39 MB (00.50%) -- script-data
│   ├───8.00 MB (02.88%) -- stack
│   ├───3.18 MB (01.14%) -- (9 omitted)
│   └───1.53 MB (00.55%) -- compartment(atoms)
│       └──1.53 MB (00.55%) -- (2 omitted)
├───17.23 MB (06.20%) -- dom
├────3.39 MB (01.22%) -- storage
│    ├──3.31 MB (01.19%) -- sqlite
│    │  └──3.31 MB (01.19%) -- (11 omitted)
│    └──0.08 MB (00.03%) -- (1 omitted)
└────2.12 MB (00.76%) -- (6 omitted)

Resident Set Size (RSS) Breakdown

Proportional Set Size (PSS) Breakdown

Virtual Size Breakdown

Swap Usage Breakdown

Other Measurements
    0.05 MB -- gfx-surface-image
1,830.81 MB -- gfx-surface-xlib
  259.22 MB -- heap-allocated
  273.76 MB -- heap-committed
      5.30% -- heap-committed-fragmentation
    2.55 MB -- heap-dirty
  117.78 MB -- heap-unallocated
          2 -- js-compartments-system
          4 -- js-compartments-user
    9.00 MB -- js-gc-heap
    0.40 MB -- js-gc-heap-arena-unused
    0.00 MB -- js-gc-heap-chunk-clean-unused
    0.61 MB -- js-gc-heap-chunk-dirty-unused
    0.00 MB -- js-gc-heap-decommitted
     11.22% -- js-gc-heap-unused-fraction
    1.24 MB -- js-total-analysis-temporary
    0.46 MB -- js-total-mjit
    3.56 MB -- js-total-objects
    2.46 MB -- js-total-scripts
    2.84 MB -- js-total-shapes
    1.70 MB -- js-total-strings
    0.30 MB -- js-total-type-inference
        765 -- page-faults-hard
    519,942 -- page-faults-soft
  294.71 MB -- resident
  947.69 MB -- vsize

Comment 2

[:aceman]

Yes, it looks like the OOM killer kills firefox because the RAM is full. It seems there is 4GB of RAM on the system. Firefox only takes 1.2GB when killed. So other programs take the rest of it. Is it a 64bit system (looks like that from the kernel name)? You have not enabled any SWAP space. So you can't use so many programs simultaneously. If Firefox takes "only" 1,2GB, it is not that bad to cause it to crash (if there are about 3000 images). I haven't looked at the page so far to confirm.

Comment 3

[Anael Mobilia]

Hi,

I try again today, with a safe-mode of the latest FF 9beta.
The crash occurs later today : like 5 minutes after the full load of the page.
During these 5 minutes, the computer was really slowed down (the gui was lagging)

My computer have 4GB of RAM, and no swap partition. The OS is Debian 6.0.3, 64bits version.

Today, I monitor the RAM usage, it was still under 25% . Yesterday, it was the same idea, with an average of 50% or RAM used.

The webpage contains :
 - 3020 pictures, only jpg, with a total size of 170MB
 - 1 HTML document (not w3c valid) of 2.3MB

So : 
 - Firefox crash, on using 1.2GB of RAM, for a webpage of +/- 180 MB.
 - Firefox is killed by a oomkiller, but the RAM is used at +/- 25%

Have you any idea ?

Comment 4

[Anael Mobilia]

Attachment: Dmesg log (2nd crash)

Dmesg log for my comment on the 2011-11-23 12:05:11 PST

Comment 5

[:aceman]

OOM kill means the OS decided there is too few free memory left for normal operation so must decide which process to kill to free memory. It decided the best process is Firefox because it has a lot of memory allocated and rapidly allocates more and more. This is normal system behavior.

My idea is that you are overloading your system. You simply can't view that big page while you have other programs running and taking 3GB of RAM. But I can't see if this is true. From the dmesg log I don't see how much the other programs take. But it seems there is only about 100MB free when the OOM killer starts its thing. But there are 801738 pagecache pages (disk cache) so about 80% of system RAM so there is plenty of RAM to free. I do not know why the OOM killer is doing this. There is a list of processes at the end of the log. Are those all your running processes? They aren't really taking much memory (not 3GB). They actually take too few RAM, looking at the RSS column.
You'd need to ask some Debian/Linux guru about why the kernel is doing this.
I do not know how 64bit system behaves, I do not have one. Thomas in comment 1 has one, and it doesn't happen for him.
Can you try the page in other browsers? How much memory do they take? Are they killed too?

Comment 6

[Anael Mobilia]

Hello,

I open the webpage on the same PC with epiphany (2.30.6, default version for debian 6.0.3). It takes ~330MB of RAM.
No OOM kill or problem related.

I test on a second laptop, based on Ubuntu 11.10, with 4GB of RAM and 4GB of swap partition :
-> on google Chrome (7.0.517.44), it takes ~290MB of RAM. No crash.
-> on Firefox 8 (with Ubuntu integration modules), it takes 1,5GB of RAM. I can minimize RAM usage to ~300MB, but then FF freeze (but don't crash) and requiere the creation of 1Go of swap memory (the swap was created as FF was at 60% of the CPU during 5 minutes).

Is it a problem linked to FF 9 or to the swap ?
Why so many RAM usage (in comparaison with other web browser) ?

Regards,
Anael

Comment 7

[Anael Mobilia]

Important information : the second computer was base on a i386 version of ubuntu, not a x64 !

Comment 8

[Anael Mobilia]

On Windows 7 32 bits, and FF7.0.1, the webpage crash.
Report can be found at : https://crash-stats.mozilla.com/report/index/bp-7ba92c7e-9972-4c4c-bc55-ba6842111128

On the same OS, with FF 8.0.1, crash again.
Report is at https://crash-stats.mozilla.com/report/index/bp-31fb72c7-e8f5-456b-93d7-4f74c2111128

Regards,
Anael

Comment 9

[:aceman]

For some reason the crash reports are incomplete, show no useful data. I don't know why that is.
So you now say FF crashes on the same page also in Windows 7?
It is true that Firefox handles some cases with images much worse than other browsers. See bug 683284 and its dependencies.

It could be that on your 32bit systems (ubuntu and Win7), Firefox process is only allowed to use 2GB of RAM (hardware reason) and is killed if it achieves this. You say you could open the page on FF8 on Ubuntu i386 (32bit). It may just happen that if you open only that page, it fits into 2GB. If you open another tab alongside it, it takes FF over the limit.

Comment 10

[Anael Mobilia]

Hi aceman,

I open only one tab to make the test.

For a 32bits system, the max addressable memory is 3.3 GB for me. Is it a particular limitation per process ?

Can I made a more complete report of crashes ? A dump to copy, a specific command ?

Regards

Comment 11

[:aceman]

I think there is a per process limit of 2GB (on 32bit OS). But I am not an expert in this 32bit/64bit stuff.

You need to find out if Firefox hits 2GB and is then killed by the OS. Start Task manager and watch firefox process memory usage (virtual and also private (RSS, RES)). Then load the page and watch the memory usage grow. Make the list refresh quickly. See if it hits 2GB (2048MB) and then disappears.

Comment 12

[gabe]

this thing is diffently a bug effects windows 7 and firefox 64 bit it doesnt crash but goes memory and hang heavy

Comment 13

[Nickolay_Ponomarev]

This is very similar to bug 622397, bug 683284, and others.