[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.3.51 -- I am still seeing the"shmget: shm filesystem not mounted" error
Alan Cox wrote:
> I'd disagree. The remove and attach technique is very very commonly used
> by other applications in order to ensure the segment is deleted if a program
> crashed - directly analogous to open/unlink/read.

The problem is that shm segments are like temporary files in a lot of
way. You can't do open/unlink pass the name of a tmp file to another
program either -- so why should you be able to do it with shm segments?

To do open/unlink with multiple programs, you need some way to pass a
file descriptor around.

Besides, the creat/remove technique _still_ leaks from time to time. I
have seen it -- more and more shm segments being added because a program
crashed between the create and the remove.

> Gimp wont be the only thing that breaks. So the old behaviour needs to work
> at least for SYS5 IPC, what posix ipc does is another matter

I propose we wait and see what else breaks.

I would really like to see programs motivated to use a file descriptor
passing method for X. Currently these things can go wrong with X SHM:

- The X connection is local, so you create a SHM segment. But the
server is remote via a local proxy (an increasingly common
arrangement), so the SHM fails. Some programs fall over at this
point, but they can be fixed to fall back.

- Same scenario but the server finds a SHM segment on it's system
with the id you passed. Very bad: you think it succeeded, but the
wrong images appear. It can even be a security hole.

- Same again but you're reading images from X. E.g. to read font
bitmaps. Very bad: you just trashed another applications shm

- Segments tend to get leaked because programs sometimes crash
before IPC_RMID. On some systems, the total space is limited too,
so you can't afford to have lots of them. Maybe this happens less
with Linux. Typical fix: a script to delete bogus shms is run at
the start of the application. Result: application occasionally
breaks other applications or instances of itself.

These are typical, but easily fixed application problems:

- The server is local but on a different IP to your standard
address. You neglect to check all alias addresses so you don't
use SHM even though you probably should.

- You check for SHM extension, find it, try SHM and it fails. You
crash. Yes I've seen this.

All the mess I can think of, including the "maps wrong SHM segment"
problem are all fixed nicely by using fd passing over a unix socket.
That, IMO, is the friendly way to establish a shm area with the X

-- Jamie

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean