linux-kernel - OOM in 2.6.19-rc*

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 Nov 2006 16:40:17 +0000 (GMT)
From:	Christian Kujau <evil@...ouse.de>
To:	linux-kernel@...r.kernel.org
Subject: OOM in 2.6.19-rc*

Hello,

a few days ago I upgraded my desktop machine (x86_64) to ubuntu/edgy 
thus completely changing the userland. Since I'm using kernel.org 
kernels I upgraded to a current kernel as well (2.6.19-rc4-git from Nov 
4 and 2.6.19-rc4-mm2). Now, while working under X11, probably reading 
email, all of a sudden the machine was not responsible any more and the 
disk was spinning like wild. The desktop applet showed all swap being 
used up then the display froze too and ~5 min later the machine came 
back with the gnome-login screen: it had not rebooted but ran OOM and 
several apps got killed.

OK, must be some application leaking memory, I thought, that's what 
happens to new userland version. Looking at the syslog, "nautilus" 
(gnome filemanager) invoked the oom killer. OK, but the scenario 
repeated the next day, early in the morning when I was not even on the
box, saying it was nautilus again.
In the last days other applications seem to invoke the OOM killer as
well and I wonder if each one of them is really to blame for leaking 
memory or something else would be responsible for the killings. Here's 
log output, each listing the first appliction triggering the OOM killer:

# for i in /var/log/messages*; do (zgrep "invoked" "$i" | head -1 ); done
Nov 11 08:04:16 prinz64 kernel: [104237.902269] firefox-bin invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 10 07:59:34 prinz64 kernel: [64627.382818] Xorg invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov  9 07:59:22 prinz64 kernel: [25047.487534] rpc.idmapd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=-17
Nov  8 17:33:59 prinz64 kernel: [  919.954547] beep-media-play invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov  7 18:55:23 prinz64 kernel: [  842.590646] firefox-bin invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov  5 07:55:34 prinz64 kernel: [18128.545690] nautilus invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov  4 17:31:23 prinz64 kernel: [  688.904652] nautilus invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0

The kernels running when these were happening:
Nov  4 - 2.6.19-rc2
Nov  5 - 2.6.19-rc2
Nov  7 - 2.6.19-rc4-mm2
Nov  8 - 2.6.19-rc4
Nov  9 - 2.6.19-rc4
Nov 10 - 2.6.19-rc4
Nov 11 - 2.6.19-rc4

Because killing these application does not seem to free up memory, 
plenty of other applications got killed shortly after this. Full logs
and .config can be found here: http://nerdbynature.de/bits/2.6.19-rc4/

I do notice anacron running just before the killings - but: even *if* 
anacron runs a mem-leaking program: should the OOM killer just kill that 
app and not the (probably) innocent ones in the first place?

Thanks for your thoughts,
Christian.
-- 
BOFH excuse #194:

We only support a 1200 bps connection.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/