Posix shared memory problem

[Nikos Ntarmos]

On Sun, May 10, 2009 at 01:00:16AM -0400, Garrett Wollman wrote:
> In <mit.lcs.mail.freebsd-arch/19461540.20090510064924 at scriptolutions.com>
> scholz at scriptolutions.com writes:
> 
> >JT> shm_open/shm_unlink refer to the filesystem; they are fairly direct
> >JT> wrappers around open and unlink.
> >
> >Question is where are they stored?
> 
> In the fileststem, in the path that you specify.  They are just
> ordinary files.
> 
> There was some thought that this was a bad (or at least
> not-like-Linux) way of implementing this feature, so I believe
> more-recent versions of FreeBSD do it differently.  When I wrote this
> code, I could not see any reason for the "path" argument to be
> interpreted differently from any other path.

FWIW the test code in the original email still fails even if an absolute
path is used as a sem name, ie:
	sem_t *s = sem_open("/path/to/foobar", O_CREAT | O_EXCL, S_IWUSR, 0);
with /path/to/foobar pointing to a user writable directory, segfaults
with "invalid system call". Note that the error is not printed by
perror(3) but by the system itself. A backtrace of the resulting core
shows that the problem is burried deep in ksem_open():

ntarmos at ace:~% ./ts
zsh: invalid system call (core dumped)  ./ts
ntarmos at ace:~% gdb -q ./ts ts.core
Core was generated by `ts'.
Program terminated with signal 12, Bad system call.
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x280c214b in ksem_open () from /lib/libc.so.7
(gdb) bt
#0  0x280c214b in ksem_open () from /lib/libc.so.7
#1  0x280b78fc in sem_open () from /lib/libc.so.7
#2  0x080484e5 in main () at test-sem.c:7
(gdb) 

This is on i386/7.2-RELEASE.

Cheers.

\n\n