Do anyone has any problem with sem_open() crash?

[Robert Watson]

On Sun, 22 Oct 2006, Kris Kennaway wrote:

> On Sun, Oct 22, 2006 at 08:48:20PM -0500, Jeremy Messenger wrote:
>
>> I guess I am safe then as I can ignore these cores.. Thanks! Isn't kernel 
>> supposed to be avoid the crash? I don't see any of crash before I upgraded 
>> to last night of RELENG_6.
>
> It's not a crash, it's a configure script testing whether the syscall 
> exists, and the the test program gets the signal 12 to tell it that it 
> doesn't. This is expected behaviour.

We have several levels of "But that's not implemented".  The level used for 
system calls that are simply not defined is SIGSYS+ENOSYS.  By default, 
application calling these (undefined) system calls can catch the error if they 
choose to, but will exit otherwise.  The next level is to provide ENOSYS stubs 
that return ENOSYS without generating SIGSYS; in some situations, this is 
preferred.  For example, we use this when AUDIT isn't compiled into the kernel 
but login(1) calls an audit system call to see if audit is present.  Finally, 
there are a number of situations where a system call is implemented, but the 
underlying object doesn't support the operation, in which case we often return 
EOPNOTSUPP or variations on that them.

The SIGSYS+ENOSYS error code isn't a bug, but it seems likely that configure 
would be a lot happier if we returned ENOSYS without SIGSYS.  Right now, that 
means hand-defining a stub that's conditionally compiled based on the feature 
not being present.  It might be nicer if we had a way to indicate that in the 
system call table.

Robert N M Watson
Computer Laboratory
University of Cambridge