lkml.org 
[lkml]   [1997]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible Kernel Memory Leak in 2.0.28
> In article <m0vpkZF-0005FfC@lightning.swansea.linux.org.uk>,
> alan@lxorguk.ukuu.org.uk (Alan Cox) wrote:
>
> >> any rate, this deallocates the memory and stabilized my system.. Is
> >> there any reason why shared memory belonging to defunct processes is
> >> not automatically deallocated?
> >
> >SYS5 designers decided it would be useful to be able to leave this sort of
> >state around for other programs to reopen. Yes its stupid, but we are
> >kind of stuck with it. Gimp should create the shared memory, attach it,
> >delete it and then use (the delete occurs on the end of the last attach)
> >
> Does this mean: If I have running a process which allocated some
> chunks of shared memory, and that process crashes, the shmem won't be
> deallocated ?
Yes and no. The way around this is to create the shm, attatch it and also do
the shmctl(id, IPC_RMID, 0) at creation time. It will then be deallocated when
the last process detatches from it (either explicitly or by exiting).

Unfortunately this doesn't work for semaphore blocks as doing semctl(id, 0,
IPC_RMID, 0) deltes the resource now, not later :-(

David
>
> --
> # /AS/ #
> # http://members.ping.at/alexa/ God save the screen ! #


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.054 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site