Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!69.16.185.21.MISMATCH!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system Subject: Re: problem with core dumps and multi-threaded daemon Date: Mon, 18 Jul 2011 19:54:42 +0100 Lines: 31 Message-ID: <87pql7e7wt.fsf@sapphire.mobileactivedefense.com> References: <64909bbc-5fb3-4ceb-9bba-2b75eec6b158@h7g2000prf.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net SkJG2znkUIOi97ZdU/htyAFrGTG6PQQtAf+d02ZvwzWa/CWhM= Cancel-Lock: sha1:6XfrOtY74vBXNpAyp53D+5pKsSk= sha1:g+8Fs107x/8X0rvUqvP0J5ADjmg= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.system:221 Gorlash writes: > I'm using Ubuntu server 10.10 (2.6.35-22-generic-pae) > I have a daemon running on my system, and it processes tcp packets and > other data sources, using multiple pthreads. I'm finding that every > once in awhile it generates a segfault, and I'm trying to get some > clues as to what is going wrong. All I get in /var/log/messages is: > Jul 18 11:15:32 u10hub kernel: [ 8688.898805] grunion[11319]: segfault > at b77ea000 ip 00688fb6 sp b77e7b18 error 6 in > libc-2.12.1.so[613000+157000] > > I've added SIGSEGV to the list of signals that I monitor, but it does > not appear to to get invoked (though it *does* get invoked if I send > 'sudo killall -11 grunion'). > > I tried getting it to generate a coredump by setting 'ulimit -c > unlimited', and 'ulimit -a' shows that being set as requested, but > when it segfaulted most recently, there was no core file that I could > find. If the process is handling the signal, the kernel probably doesn't generate a coredump. [...] > with a daemon, which doesn't really have a home directory, where > would the core file get generated? The 'home directory' doesn't matter here: A coredump is dumped into the current working directory of the process whose core is about to be dumped, provided the user this process runs as is allowed to write to that.