Date: Sun, 10 May 2009 22:41:33 +0300 From: Nikos Ntarmos <ntarmos@cs.uoi.gr> To: arch@freebsd.org Subject: Re: Re[2]: Posix shared memory problem Message-ID: <20090510194133.GG20749@ace.cs.uoi.gr> In-Reply-To: <200905100500.n4A50GOa050728@hergotha.csail.mit.edu> References: <mit.lcs.mail.freebsd-arch/588815840.20090509203115@scriptolutions.com> <mit.lcs.mail.freebsd-arch/20090509200724.GA25714@stack.nl> <200905100500.n4A50GOa050728@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 10, 2009 at 01:00:16AM -0400, Garrett Wollman wrote:
> In <mit.lcs.mail.freebsd-arch/19461540.20090510064924@scriptolutions.com>
> scholz@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@ace:~% ./ts
zsh: invalid system call (core dumped) ./ts
ntarmos@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090510194133.GG20749>