(cc: to [EMAIL PROTECTED] and to [EMAIL PROTECTED] - 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
(gdb)
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,
shmflg=0)
ipcs refcount=2
X Breakpoint 15, shmctl (shmid=567279622, cmd=2,
buf=0xbffff1fc)
(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,
shmflg=0)
0x00000000 698023942 david 777 32768 1
X - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0,
shmflg=0)
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
dest
E - Breakpoint 4, shmget (key=0, size=524288, shmflg=1023)
E - Breakpoint 1, shmat (shmid=698056711, shmaddr=0x0,
shmflg=0)
0x00000000 698056711 david 777 524288 1
X - Breakpoint 2, shmdt (shmaddr=0x40015000)
(first segment removed)
Here is what enlightenment is doing (invert the part
sequence):
(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,
dsk=0x8114430,
setbg=1 '\001') at desktops.c:912
[...]
#2 0x4019396e in _XRead (dpy=0x8107e80,
data=0xbfffc19c "\\\002\b\001q\030(J\001", size=32) at
XlibInt.c:1032
#3 0x4019428b in _XReply (dpy=0x8107e80, rep=0xbfffc19c,
extra=0,
discard=1)
at XlibInt.c:1667
#4 0x401900fe in XSync (dpy=0x8107e80, discard=0) at
Sync.c:41
[more to come - dinner calls - please feel free to comment and provide
information]
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard
