[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#636454: marked as done (Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child)

Your message dated Wed, 3 Aug 2011 13:28:49 +0200
with message-id <20110803112849.GC3444@elie.Hillsp>
and subject line Re: Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child
has caused the Debian Bug report #636454,
regarding Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
636454: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636454
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---

Subject: linux-source-3.0.0: Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child

Package: linux-source-3.0.0

Severity: important


I just got the following in dmesg:


[43627.304569] Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice

child

[43627.304571] Killed process 3254 (Xorg) total-vm:595596kB, anon-rss:482176kB,

file-rss:368kB


Needless to say, not a nice interuption to my work :/


Looking through the dmesg log I notice it has killed firefox-bin and kdevelop a

few times before, which explains some "unexpected crashes" I thought had

occurred.


The only obvious solutions are to install more RAM (I currently have 4 GB) or

enable swap (not set up since I'm running off an SSD).


But failing this, I don't find the kernel's current behaviour very acceptable.

Killing processes without user permission isn't nice since it may lose work;

doing so and not telling the user why it suddenly died is worse. Even worse is

killing the xserver which is the parent of most other processes!


In the ideal world the kernel would stop things before RAM ran out completely

and nicely request processes to free memory or end or even ask the user what to

do, but that doesn't seem like it's likely to happen soon. Still, I find

killing the x-server unacceptable. Do you have any ideas what might be done?


Cheers,

Diggory



-- System Information:

Debian Release: wheezy/sid

APT prefers testing

APT policy: (500, 'testing'), (500, 'stable')

Architecture: amd64 (x86_64)


Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash



--- End Message ---
--- Begin Message --- 
Hi,

Diggory Hardy wrote:

> [43627.304569] Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child
> [43627.304571] Killed process 3254 (Xorg) total-vm:595596kB, anon-rss:482176kB, file-rss:368kB
>
> Needless to say, not a nice interuption to my work :/
>
> Looking through the dmesg log I notice it has killed firefox-bin and kdevelop a
> few times before, which explains some "unexpected crashes" I thought had
> occurred.
>
> The only obvious solutions are to install more RAM (I currently have 4 GB) or
> enable swap (not set up since I'm running off an SSD).

Yes, you need swap.  Maybe you could have luck putting a swap
partition on a throwaway USB thumb drive or setting aside some real
memory to hold compressed data as swap (as in the
http://code.google.com/p/compcache/ project).

Otherwise you can try disabling overcommit:

	# to try it:
	echo 2 >/proc/sys/vm/overcommit_memory

	# to make it permanent:
	echo vm.overcommit_memory = 2 >/etc/sysctl.d/dont-overcommit.conf

But I warn you, that setting makes for an unpleasant life --- for
example, a process that has allocated 2 GiB of virtual memory would
not be able to fork() in order to launch another program.  Expect
aptitude to run out of memory often.  Mitigating that properly would
require implementing posix_spawn() in the kernel instead of emulating
it in libc with fork + exec.  Documentation/vm/overcommit-accounting
has details.

Closing since it is not obvious how to turn this report into an
improvement to the kernel.  If you have specific ideas for improving
the OOM killer's heuristics, we'd still be glad to hear them.  See
"Out-of-memory handling" in the list at http://lwn.net/Kernel/Index/
for inspiration.

Thanks,
Jonathan

--- End Message ---
Reply to: