Date: Thu, 27 Jan 2005 00:52:50 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Paul Schmehl <pauls@utdallas.edu> Cc: freebsd-questions@freebsd.org Subject: Re: Finding the source of a sigill Message-ID: <Pine.NEB.3.96L.1050127005011.38155C-100000@fledge.watson.org> In-Reply-To: <8C20281367ADB834E95B5684@utd49554.utdallas.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050127005011.38155C-100000>