461154 - crash: firefox-bin invoked oom-killer

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Alex J. Avriette]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081022 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081022 Minefield/3.1b2pre

I am not sure what happened; when I got in this morning, I had a pile of junk in syslog, and firefox had crashed, leaving a few processes running, but without windows attached to them (windowing environment is kde 4.1 on hardy x64). The syslog output is lengthy, so I've added it to the "additional information" field below.

For what it's worth, this looks like it may be linux-side, not firefox-side to me.

Reproducible: Didn't try

Steps to Reproduce:
1.
2.
3.



Oct 22 05:11:13 rancor kernel: [1349095.198883] firefox-bin invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Oct 22 05:11:14 rancor kernel: [1349095.198892] Pid: 3733, comm: firefox-bin Tainted: P        2.6.24-19-generic #1
Oct 22 05:11:14 rancor kernel: [1349095.198894] 
Oct 22 05:11:14 rancor kernel: [1349095.198894] Call Trace:
Oct 22 05:11:14 rancor kernel: [1349095.198933]  [oom_kill_process+0xf6/0x110] oom_kill_process+0xf6/0x110
Oct 22 05:11:14 rancor kernel: [1349095.198939]  [out_of_memory+0x15e/0x270] out_of_memory+0x15e/0x270
Oct 22 05:11:14 rancor kernel: [1349095.198945]  [<ffffffff80253a00>] autoremove_wake_function+0x0/0x30
Oct 22 05:11:14 rancor kernel: [1349095.198953]  [__alloc_pages+0x3b9/0x3f0] __alloc_pages+0x3b9/0x3f0
Oct 22 05:11:14 rancor kernel: [1349095.198967]  [__do_page_cache_readahead+0xe0/0x210] __do_page_cache_readahead+0xe0/0x210
Oct 22 05:11:14 rancor kernel: [1349095.198982]  [nfs:filemap_fault+0x28e/0x570] filemap_fault+0x28e/0x390
Oct 22 05:11:14 rancor kernel: [1349095.198992]  [__do_fault+0x6a/0x430] __do_fault+0x6a/0x430
Oct 22 05:11:14 rancor kernel: [1349095.199006]  [handle_mm_fault+0x1b2/0x7b0] handle_mm_fault+0x1b2/0x7b0
Oct 22 05:11:14 rancor kernel: [1349095.199011]  [getname+0x1a9/0x220] getname+0x1a9/0x220
Oct 22 05:11:14 rancor kernel: [1349095.199024]  [do_page_fault+0x1ab/0x840] do_page_fault+0x1ab/0x840
Oct 22 05:11:14 rancor kernel: [1349095.199040]  [sys_newstat+0x36/0x50] sys_newstat+0x36/0x50
Oct 22 05:11:14 rancor kernel: [1349095.199050]  [error_exit+0x0/0x51] error_exit+0x0/0x51
Oct 22 05:11:14 rancor kernel: [1349095.199066] 
Oct 22 05:11:14 rancor kernel: [1349095.199067] Mem-info:
Oct 22 05:11:14 rancor kernel: [1349095.199068] Node 0 DMA per-cpu:
Oct 22 05:11:14 rancor kernel: [1349095.199071] CPU    0: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:   1 usd:   0
Oct 22 05:11:14 rancor kernel: [1349095.199073] CPU    1: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:   1 usd:   0
Oct 22 05:11:14 rancor kernel: [1349095.199074] Node 0 DMA32 per-cpu:
Oct 22 05:11:14 rancor kernel: [1349095.199076] CPU    0: Hot: hi:  186, btch:  31 usd: 176   Cold: hi:   62, btch:  15 usd:  61
Oct 22 05:11:14 rancor kernel: [1349095.199079] CPU    1: Hot: hi:  186, btch:  31 usd: 171   Cold: hi:   62, btch:  15 usd:  57
Oct 22 05:11:14 rancor kernel: [1349095.199080] Node 0 Normal per-cpu:
Oct 22 05:11:14 rancor kernel: [1349095.199082] CPU    0: Hot: hi:  186, btch:  31 usd: 151   Cold: hi:   62, btch:  15 usd:  61
Oct 22 05:11:14 rancor kernel: [1349095.199084] CPU    1: Hot: hi:  186, btch:  31 usd: 181   Cold: hi:   62, btch:  15 usd:  59
Oct 22 05:11:14 rancor kernel: [1349095.199087] Active:1417777 inactive:18793 dirty:0 writeback:0 unstable:0
Oct 22 05:11:14 rancor kernel: [1349095.199088]  free:8318 slab:8712 mapped:12087 pagetables:8975 bounce:0
Oct 22 05:11:14 rancor kernel: [1349095.199089] Node 0 DMA free:11280kB min:16kB low:20kB high:24kB active:0kB inactive:0kB present:10820kB pages_scanned:0 all_unreclaimable? yes
Oct 22 05:11:14 rancor kernel: [1349095.199092] lowmem_reserve[]: 0 2999 6029 6029
Oct 22 05:11:14 rancor kernel: [1349095.199095] Node 0 DMA32 free:17052kB min:4940kB low:6172kB high:7408kB active:2961564kB inactive:40544kB present:3071980kB pages_scanned:8843912 all_unreclaimable? yes
Oct 22 05:11:14 rancor kernel: [1349095.199098] lowmem_reserve[]: 0 0 3030 3030
Oct 22 05:11:14 rancor kernel: [1349095.199101] Node 0 Normal free:4940kB min:4988kB low:6232kB high:7480kB active:2709544kB inactive:34628kB present:3102720kB pages_scanned:11372363 all_unreclaimable? yes
Oct 22 05:11:14 rancor kernel: [1349095.199104] lowmem_reserve[]: 0 0 0 0
Oct 22 05:11:14 rancor kernel: [1349095.199106] Node 0 DMA: 6*4kB 3*8kB 4*16kB 5*32kB 4*64kB 6*128kB 3*256kB 2*512kB 2*1024kB 1*2048kB 1*4096kB = 11280kB
Oct 22 05:11:14 rancor kernel: [1349095.199113] Node 0 DMA32: 2233*4kB 1*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 1*4096kB = 17052kB
Oct 22 05:11:14 rancor kernel: [1349095.199119] Node 0 Normal: 69*4kB 1*8kB 1*16kB 1*32kB 0*64kB 0*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 4940kB
Oct 22 05:11:14 rancor kernel: [1349095.199126] Swap cache: add 0, delete 0, find 0/0, race 0+0
Oct 22 05:11:14 rancor kernel: [1349095.199128] Free swap  = 0kB
Oct 22 05:11:14 rancor kernel: [1349095.199129] Total swap = 0kB
Oct 22 05:11:14 rancor kernel: [1349095.199130] Free swap:            0kB
Oct 22 05:11:14 rancor kernel: [1349095.240183] 1835008 pages of RAM
Oct 22 05:11:14 rancor kernel: [1349095.240186] 351284 reserved pages
Oct 22 05:11:14 rancor kernel: [1349095.240187] 409819 pages shared
Oct 22 05:11:14 rancor kernel: [1349095.240188] 0 pages swap cached

Comment 1

[cmtalbert]

dougt: is there any chance the OOM stuff you added for fennec could be causing this?

Comment 2

[Doug Turner (:dougt)]

nope.

Comment 3

[timeless]

this isn't technically a crash. The log shows gecko used around 1.8gb of vm, and your system having no free swap/memory had to kill firefox because while it had promissed additional memory to firefox, it didn't have it. - linux plays an amusing game... i can't remember if it's called liar's bluff or something else. But to use a different expression, the kernel got caught with its pants down. a more current analogy, think of your computer's os like a bank, e.g. a bank of iceland. The bank promises a series of loans/investments and banks on turnover and that not everyone will ask for all their money(memory) at the same time. But in this case.... the bank made a promise and when firefox came to collect the money(memory) to use it, the bank(os) said "oops" i can't cover that loan. Now a bank has a few choices, it can just close (computer panics and you lose everything), or it can go into receivership. Normally the bank just asks for a loan (swap) and is able to continue to function. But if it can't get a loan (too expensive, maybe you configured the computer not to give them?), then it has too do something about the current transaction. Unlike a typical bank, the os can fire/kill its customer. The real customer won't be very happy (it loses everything), but the bank can try to recover for the rest of its customers (see FDIC insurance for an example). Anyway, the alternatives: 1. The bank defaults on everyone (full panic, box is dead and may reboot or simply halt) 2. You change the banking laws to refuse to allow overdrafts (/proc/sys/vm/overcommit_memory) 3. You increase liquidity (enable swap, add swap) 4. Offer "unlimited liquidity" in the form of dynamic swap (disk backed, not quite a federal reserve loan)

Comment 4

[Jesse Ruderman]

Or we could try to figure out why Firefox was using so much memory.  We could use specific steps to reproduce "high memory use", or debugging output that shows what objects are being leaked or held too long.  (See https://wiki.mozilla.org/Performance:Leak_Tools.)

Comment 5

[Jesse Ruderman]

(But please file a new 'footprint' or 'mlk' bug rather than continuing here.)