Date: Mon, 08 Apr 2002 22:06:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: callum.gibson@db.com Cc: hackers@freebsd.org Subject: Re: ipcrm/shmctl failure Message-ID: <3CB276CB.89703872@mindspring.com> References: <20020408225938.2069.qmail@merton.aus.deuba.com>
next in thread | previous in thread | raw e-mail | index | archive | help
callum.gibson@db.com wrote:
> I'm running FreeBSD 4.5-RELEASE on 2 machines. Yesterday one of them
> ran out of shared memory segments (used by wine, X11 and mozilla).
> Fine, clean them up. However although I could list them with ipcs,
> the vast majority could not be removed, even as root with ipcrm failing
> with "Invalid argument". I also have a program which implements ipcrm
> (en masse) with shmctl(2) and it fails similarly (EINVAL). In short I
> could only clear these by rebooting.
Use the source:
case IPC_RMID:
error = ipcperm(p, &shmseg->shm_perm, IPC_M);
if (error)
return error;
shmseg->shm_perm.key = IPC_PRIVATE;
shmseg->shm_perm.mode |= SHMSEG_REMOVED;
if (shmseg->shm_nattch <= 0) {
shm_deallocate_segment(shmseg);
shm_last_free = IPCID_TO_IX(uap->shmid);
}
break;
All you are doing is marking the segment as removed. The segment
remains attached by the processes which have it open, and those
references don't go awaya until the processes in question detach
the segments, and the reference count goes to zero.
In other words, shared memory segments are like files; you can't
delete them out from under programs that still hold references
to them.
> The only other thing that could be relevant is that I do use the linux
> mozilla so perhaps it has something to do with creation of the shm
> under linux emulation? (I did try running a linux ipcrm binary just
> in case - same error.) This may be a red herring because as far as I
> can tell the nonremovable ones this morning were created by X (I only
> ran a few xterms, xclock, xload).
This is probably because of the shared memory segments that
are established for bitmaps, using the shared memory extension
to the X server.
It turns out that these segments are not proerly reference
counted and tracked, so they are not deleted when the client
"goes away".
This is a bug in the MIT shared memory extension for X design,
and can't be fixed for long running programs with lots of
bitmaps.
You can either quit your Netscape (Mozilla; whetever) and then
restart it, or you can tell it not to use the shared memory
extension to communicate with the X server. The way to do this
is to set your DISPLAY environment variable so that clients use
network connections, not local (UNIX) domain sockets, to talk
to the X server... e.g.:
setenv DISPLAY `hostname`:0.0
> Also the manpage mentions a file-based implementation. Where are the
> files kept? With this in mind, the only other thing I might mention is
> that I have an mfs /tmp (on both machines).
It does not use a file based implementation; your Linux man page
is wrong.
> I can't see any previous mention of this on questions, hackers or current
> nor in the PR database. Has anyone else seen this? It should be easy to
> repeat I would have thought as I'm not doing anything unusual.
It's an X11 question, and it's been that way since at least 1994,
so it's a long standing X11 FAQ.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CB276CB.89703872>