From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 15:28:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0F2916A4BF for ; Thu, 21 Aug 2003 15:28:55 -0700 (PDT) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCFC43FBD for ; Thu, 21 Aug 2003 15:28:55 -0700 (PDT) (envelope-from vlm@netli.com) Received: (qmail 1309 invoked by uid 84); 21 Aug 2003 22:28:55 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.148375 secs); 21 Aug 2003 22:28:55 -0000 Received: from unknown (HELO netli.com) (172.17.1.12) by mx01-pal-lan.netli.lan with SMTP; 21 Aug 2003 22:28:54 -0000 Message-ID: <3F4548C3.8050601@netli.com> Date: Thu, 21 Aug 2003 15:33:39 -0700 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030820 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Artem 'Zazoobr' Ignatjev References: <1061503060.1030.4.camel@timon.nist> <3F454218.4010209@netli.com> <1061503658.1030.8.camel@timon.nist> In-Reply-To: <1061503658.1030.8.camel@timon.nist> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Dumping a core from inside of process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 22:28:56 -0000 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