From owner-freebsd-stable@FreeBSD.ORG Mon Oct 23 11:17:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30FC716A492 for ; Mon, 23 Oct 2006 11:17:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B4E643D60 for ; Mon, 23 Oct 2006 11:17:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0181746DCF; Mon, 23 Oct 2006 07:17:51 -0400 (EDT) Date: Mon, 23 Oct 2006 12:17:50 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <20061023020119.GA30219@xor.obsecurity.org> Message-ID: <20061023121528.L60062@fledge.watson.org> References: <1161567368.30822.31.camel@shumai.marcuscom.com> <20061023020119.GA30219@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeremy Messenger , freebsd-stable@freebsd.org Subject: Re: Do anyone has any problem with sem_open() crash? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 11:17:52 -0000 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