Re: Bug#256871: cdrecord triggers memory leak in kernel space
From: Joerg Schilling (schilling_at_fokus.fraunhofer.de)
Date: 07/04/04
- Next message: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Previous message: Eduard Bloch: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Maybe in reply to: Andreas Metzler: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Next in thread: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Reply: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 4 Jul 2004 15:06:41 +0200 (CEST) To: 256871@bugs.debian.org
>AFAICS there were no such reports and that's what it is confusing. I do
>not count on much help from the upstream author there.
A sad truth :-(
In the past, the Linux Kernel maintainers have not been very helpful with Linux
Kernel bugs.
I did stop sending bug reports to the Linux Kernel team two years ago for this
reason. For me it makes not sense to waste my time with unwilling people.
A possible reson for this Linux kernel bug is Kernel design bug that is known
for a long time:
Linux does not keep track of the size of the processes. If e.g. a process forks,
Linux creates copy on write pages for the data segment of the fork. This idea
has been taken from SunOS ideas in the mid 1980s. Unlike SunOS, Linux does not
compute the needed virtual memory and overcommits the available size.
When a process later modifies the parts of it's address space that is just a
copy on write marked page, the kernel needs to create a second page before the
modification may take place. The space for this page may not be available and
the Linux kernel management is unable to tell which process is the cause for the
missing virtual memory space. Linux for this reason kills random processes to
regain virtual memory space. If you have a multi processor machine, it is even
worse: Linux in this case becomes catatonic and may only recover by a "reset"
induced reboot. This is caused by the way a dual or multi processor Linux
works.
BTW: As cdrecord touches all it's memory at process start, cdrercord is not one
of the processes where Linux does not know the correct process size.
J?rg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
-------------------------------------------------------------------------------
Information forwarded to debian-bugs-dist@lists.debian.org, Joerg Jaspert
<joerg@debian.org>:
Bug#256871; Package cdrecord. Full text available.
-------------------------------------------------------------------------------
Acknowledgement sent to Jeff King <peff-debbug@peff.net>:
Extra info received and forwarded to list. Copy sent to Joerg Jaspert
<joerg@debian.org>. Full text available.
-------------------------------------------------------------------------------
Message received at 256871@bugs.debian.org:
Received: (at 256871) by bugs.debian.org; 5 Jul 2004 05:56:13 +0000
- Next message: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Previous message: Eduard Bloch: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Maybe in reply to: Andreas Metzler: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Next in thread: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Reply: Jeff King: "Re: Bug#256871: cdrecord triggers memory leak in kernel space"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
