From owner-freebsd-hackers Mon Apr 8 22: 7: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 295E437B419 for ; Mon, 8 Apr 2002 22:06:47 -0700 (PDT) Received: from pool0021.cvx40-bradley.dialup.earthlink.net ([216.244.42.21] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16unq8-0006Uq-00; Mon, 08 Apr 2002 22:06:45 -0700 Message-ID: <3CB276CB.89703872@mindspring.com> Date: Mon, 08 Apr 2002 22:06:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: callum.gibson@db.com Cc: hackers@freebsd.org Subject: Re: ipcrm/shmctl failure References: <20020408225938.2069.qmail@merton.aus.deuba.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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