freebsd stable - Dec 2005 - shmget errors

Hi,

I've seen this problem discussed before on various mailinglists and forums,
but never any real solutions. 

It seems to happen right after a video player, such as totem or mplayer, has
crashed. They might crash for different reasons, but the problem afterwards is
always the same. 

Mplayer will f.ex give you the following error message:

X11 error: BadAccess (attempt to access private resource denied)

or if I try to start gvim:

(gvim:86376): Gdk-WARNING **: shmget failed: error 12 (Cannot allocate memory)

or totem:

The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadShmSeg (invalid shared segment parameter)'.
  (Details: serial 31 error_code 166 request_code 147 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

The only common thing with all these applications is gtk, though different
versions:

ldd `which mplayer`|grep tk
        libgtk12.so.2 => /usr/X11R6/lib/libgtk12.so.2 (0x289f2000)

ldd `which gvim` | grep tk
        libgtk-x11-2.0.so.0 => /usr/X11R6/lib/libgtk-x11-2.0.so.0
(0x28197000)

ldd `which totem` | grep tk
        libgtk-x11-2.0.so.0 => /usr/X11R6/lib/libgtk-x11-2.0.so.0
(0x28486000)

Seems to me that after a program such mplayer or totem crashes something is
left behind which blocks future programs from accessing certain resources.
I'm
not a programmer, so that is my very limited analysis so far.

OS: FreeBSD 5.4-STABLE (built Nov 16 2005)
Running XFree86 4.5.0 with Gnome 2.12.1 and nvidia-driver-1.0.7676_1

All gnome/gtk/glib-libs are up-to-date.

-- 
Morten A. Middelthon

"I have been Foolish and Deluded,
and I am a Bear of No Brain at All." 
		-- Pooh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051215/4a9360d1/attachment.bin

Morten A. Middelthon <morten@freenix.no> wrote:
 > I've seen this problem discussed before on various mailinglists and
forums,
 > but never any real solutions.

What you describe is an inherent problem with so-called
System-V shared memory (SysV ShMem) which doesn't have a
simple solution.  But read on for some hints ...

SysV IPC (inter-process communication) provides objects
to communicate between arbitrary processes:  shared memory
segments, semaphores and message queues.  Those objects
are _not_ automatically freed when the process terminates,
unlike other resources (such as open files or network
sockets).

That means:  When a process crashes which has opened such
SysV IPC object, then those objects will _not_ be freed,
but stay around and consume memory.  This is not a bug,
it's a feature, because those IPV objects are intended to
be used by unrelated processes, so a process may later
pick up the existing IPC objects and continue working with
them.

The problem is that those resources are limited.  You can
put hard limits on the in your kernel configuration.
Look for "SYSV IPC" in /sys/conf/NOTES.  You can also see
the values in ``sysctl kern.ipc'' and via ``ipcs -T''.

Of course, you could increase the values, but that puts the
limit only a bit further away, but it doesn't remove the
problem.  Apart from that, the "dead" reasources will take
up more and more memory.

You can see all IPC object currently existing the ``ipcs''
command.

If you have programs that create SysV IPC objects and which
are particularly prone to crash often, leaving the objects
behind, it might be best to write a small wrapper script
which calls the program and then cleans up afterwards.

Also, the following shell snippet might be helpful:

ipcs | awk '($1=="m"){print $2}' | xargs -n 1 -t ipcrm -m

It removes _all_ shared memory segments.  Be careful:
Don't do that while any programs are still running which
use SysV shared memory.  You can check that by looking at
the output of ``ipcs -p'':  If the process IDs listed under
the CPID and LPID columns don't exist, chances are that the
memory segment isn't in use anymore.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"C is quirky, flawed, and an enormous success."
        -- Dennis M. Ritchie.