Christoph Rohland wrote:
> > Recompile the Gimp and it works fine. I don't why it fails with the new
> > kernel, but the recompile does solve the problem (it did for me). Go
> > figure.
>
> The new kernel does not allow shmat to a removed segment.
>
> #strace -f -e shmget,shmat,shmctl,shmdt gimp fotos/Pingu.jpg
> [...]
> shmget(IPC_PRIVATE, 16384, IPC_CREAT|0x1ff|0666) = 950281
> shmat(950281, 0, 0) = 0x40013000
> shmctl(950281, IPC_RMID, 0) = 0
> [pid 3912] shmat(950281, 0, 0) = -1 EINVAL (Invalid argument)
Just as well. Some ancient X shm code I just looked at waits for a
confirmation event back from X before doing IPC_RMID, so I guess this
behaviour of not allowing shmat after IPC_RMID was already the case for
a certain "SunOS" some years ago.
As it should be.
I would guess that the Gimp recompile worked because of an autoconf test
that asks, "can we attach to a deleted segment?". It's a guess - I
haven't looked at the Gimp source at all.
That was potentially useful because shm segments have an unfortunate
habit of sticking around when the programs that use them die. The
earlier you can IPC_RMID those infernal things, the better.
Now that we have POSIX shm (though anon shared mappings would have been
just as good), a nice X extension would be to do shm but accept a passed
file descriptor instead of a SYSV shm id.
That way you never leak shm segments. It's more secure too -- and it
properly fails if your X connection is via a proxy: the current shm
method can even cause the X server to connect to the _wrong_ shm segment
under some circumstances (multiple hosts, coincidental ids).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:21 EST