[lkml]   [2000]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectCurrent CVS version of X does indeed break wrt SHM
(cc: to and to - this
should be the last post to LKML for this subject)

Known historical items:

-All shm segments get used up in very fast order.
-Everyone noticing it maintains it is 4.01c versioned
-It happens on multiple versions of Linux kernels, 2.2 and 2.4 (no other
OS in tests)

New items:

- I did a completely fresh checkout of X a few hours ago and built it
modular, I now get the shm bug
- I have -not- changed my kernel but I have changed kernel source.
- X itself doesn't seem to be getting the SHM segments but child
processes are and someone isn't detaching from them, particularly
starting enlightenment causes a flurry of SHM allocations.

The sequence of events by my running gdb on both X and enlightenment and
trapping all shm calls is this:

enlightenment creates and attaches to a segment
X attaches
they chit chat over the shared mem
enlightenment detaches and destroys the segment
X remains attached to the segment
...repeat until exit
at exit of X, segments are detached by default

E Breakpoint 1, shmget (key=0, size=32768, shmflg=1023)
E Breakpoint 4, shmat (shmid=567279622, shmaddr=0x0, shmflg=0)

ipcs refcount=1
X Breakpoint 13, shmat (shmid=567279622, shmaddr=0x0,
ipcs refcount=2
X Breakpoint 15, shmctl (shmid=567279622, cmd=2,
(buffer write/reads)
E Breakpoint 2, shmdt (shmaddr=0x40014000)
ipcs refcount=1
ipcs shmid marked destroyed
X is still attached to this shmid, it will not do anything
else on this shmid for the remainder of it's life.

Interim conclusion:

X is at fault. Linux kernel is fine. X simply doesn't detach any of
these client requested segments. It -does- detach the segments it
started itself.

That being said, it is very possible that X (and other processes)
depended on a default action. Recently SHM handling changed in the
Linux Kernel which is still correct but may tickle processes that need
to have code updated. I suspect X simply needs the shm handling
tweaked. I've diffed the CVS code all the way back to April and there
are no relevant SHM changes. Above we see that X does an shmctl() with
IPC_STAT as the cmd, but never detaches from it. As we see below, X
calls shmdt() the next time it gets a message from the client. In the
current CVS code it never calls shmdt()

Here's a paste of a working X compiled and installed on September 4th.

E - Breakpoint 4, shmget (key=0, size=32768, shmflg=1023)
0x00000000 698023942 david 777 32768 0
E - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0,
0x00000000 698023942 david 777 32768 1
X - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0,
0x00000000 698023942 david 777 32768 2
E - Breakpoint 2, shmdt (shmaddr=0x40014000)
0x00000000 698023942 david 777 32768 1
Breakpoint 3, shmctl (shmid=698023942, cmd=0, buf=0x0)
0x00000000 698023942 david 777 32768 1
E - Breakpoint 4, shmget (key=0, size=524288, shmflg=1023)
E - Breakpoint 1, shmat (shmid=698056711, shmaddr=0x0,
0x00000000 698056711 david 777 524288 1
X - Breakpoint 2, shmdt (shmaddr=0x40015000)
(first segment removed)

Here is what enlightenment is doing (invert the part
(gdb) bt
#0 shmat (shmid=698089478, shmaddr=0x0, shmflg=0)
at ../sysdeps/unix/sysv/linux/shmat.c:39
#1 0x40091c77 in Imlib_render (id=0x81090f0, im=0x811d4a0,
w=447, h=162)
at rend.c:6468
#2 0x8078d0a in SetBackgroundTo (imd=0x81090f0, win=2097191,
setbg=1 '\001') at desktops.c:912
#2 0x4019396e in _XRead (dpy=0x8107e80,
data=0xbfffc19c "\\\002\b\001q\030(J\001", size=32) at
#3 0x4019428b in _XReply (dpy=0x8107e80, rep=0xbfffc19c,
at XlibInt.c:1667
#4 0x401900fe in XSync (dpy=0x8107e80, discard=0) at

[more to come - dinner calls - please feel free to comment and provide


"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President

org:<img src="">
title:Blue Labs Developer
fn:David Ford
 \ /
  Last update: 2005-03-22 12:39    [W:0.214 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site