this has nothing to do with the linux kernel.
X itself does not use shm for anything. apps may use
an X extension (XSHM) which uses shm segments to exchange
image data without copying through a socket, but that's
an extension, not inherent to X.> Ok, compiling using a cvs of X i got a couple hours ago, I'm just
> wondering what the average segment number is for SHM on an X session
> that has been up for a while .... i'll get back with any sort of info
> on if the SHM problem has been solved with this latest CVS or if it
> continues to look like a kernel SHM problem. So far though,
> 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9,
> which died in 2 hours upon booting ...and it didn't have the added
> stress of compiling X.
>
> -
I think it has a lot to do with the kernel, and with X. Since
i havn't upgraded anything but X (and thus the extensions) ... now it's
obvious that X is at fault for providing us with a wonderful shared memory
leak. But, the kernel too, has something to do with it since test9
seems to be fairly unstable with it, causing all sorts of weird happenings
before totally freezing up like test8-vm3 does.
This problems only manifests in VERY recent X cvs copies so most people
will not see this problem. The problem i'm wondering about is if
the Kernel is handling shared memory correctly or if this is entirely X's
fault.
