Date: Thu, 21 Aug 2003 15:33:39 -0700 From: Lev Walkin <vlm@netli.com> To: Artem 'Zazoobr' Ignatjev <timon@memphis.mephi.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: Dumping a core from inside of process Message-ID: <3F4548C3.8050601@netli.com> In-Reply-To: <1061503658.1030.8.camel@timon.nist> References: <1061503060.1030.4.camel@timon.nist> <3F454218.4010209@netli.com> <1061503658.1030.8.camel@timon.nist>
next in thread | previous in thread | raw e-mail | index | archive | help
Artem 'Zazoobr' Ignatjev wrote: > At Thu, 21.08.2003, 22:05, Lev Walkin wrote: > >>Artem 'Zazoobr' Ignatjev wrote: >> >>>Hello, hackers >>> >>>I'm writing some program, which dlopens() a lot of shared objects, and >>>can do nasty things to it's own memory. Some day I decided to trap fatal >>>memory signals, like SIGILL, SIGBUS and SIGSEGV, and wrote a handler for >>>these, which swears with bad words into syslog, dlcloses() all that >>>objects, and quits. >> >>What if a handler dlcloses() something which is already in process of >>dlclosing() at the time the handler fires? > > No, that's the only place (except normal shutdown sequence) where the > object can be dlcosed() What if a SIGSEGV happens inside a normal shutdown sequence? My point is: it _seems_ that you're trying to do unsafe work while executing signal handler. This is off track of your main question, but does indeed suggest that the safe signal programming techniques aren't honored. >>>But today I found that it's very useful - to have coredump handy, since >>>its eases debug a lot. What is the (correct) way to make a coredump of >>>your own memory (and, it'll be nice to have all that stack frames and >>>registers written as they were when the signal did occured, not what >>>they were when we are already in signal handler) >> >>man 3 abort > > thanks, I'll take a look -- Lev Walkin vlm@netli.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F4548C3.8050601>