From owner-freebsd-questions@FreeBSD.ORG Thu Jan 27 00:53:19 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E3CA16A4CE for ; Thu, 27 Jan 2005 00:53:19 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2EFB43D5F for ; Thu, 27 Jan 2005 00:53:18 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j0R0qoGM041479; Wed, 26 Jan 2005 19:52:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j0R0qoMa041476; Thu, 27 Jan 2005 00:52:50 GMT (envelope-from robert@fledge.watson.org) Date: Thu, 27 Jan 2005 00:52:50 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Paul Schmehl In-Reply-To: <8C20281367ADB834E95B5684@utd49554.utdallas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-questions@freebsd.org Subject: Re: Finding the source of a sigill X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 00:53:19 -0000 On Wed, 26 Jan 2005, Paul Schmehl wrote: > I found this in the messages log when snort died: > > Jan 26 03:19:34 buttercup2 /kernel: pid 53186 (snort), uid 0: exited on > signal 4 > > There was no core dump. Is there a way to figure out what the cause of > the sigill was? Not easily without the core -- it's most likely a program bug, but could also be a sign of a hardware nit or OS bug. By default, setuid programs won't dump core, in order to avoid leaving core dumps that might contain "interesting" information in them. If this program is running setuid, try setting kern.sugid_coredump to 1. If it's not running setuid, but still not leaving a core dump, make sure the current working directory of the process is a directory that its credential can write to. The core dump can then be debugged as normal for an application. To test whether an application will dump core, you can artificially deliver SIGSEGV using kill -SEGV [pid], which should cause a core dump if circumstances permit. I.e., you'll need to catch the bug again, with slightly better circumstances. Robert N M Watson