From owner-freebsd-hackers Fri Oct 15 9:27: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from D2SI.COM (D2SI.COM [63.224.10.2]) by hub.freebsd.org (Postfix) with ESMTP id E4B2214CFC for ; Fri, 15 Oct 1999 09:26:55 -0700 (PDT) (envelope-from ajk@paw-in-eye.net) Received: (from ajk@localhost) by D2SI.COM (8.9.3/8.9.3) id LAA25438; Fri, 15 Oct 1999 11:23:37 -0500 (CDT) (envelope-from ajk) From: Alec Kloss Message-Id: <199910151623.LAA25438@D2SI.COM> Subject: Re: Handling segV's In-Reply-To: <19991015153003.54337.qmail@hotmail.com> from Dodge Ram at "Oct 15, 1999 8:30: 3 am" To: gupz@hotmail.com (Dodge Ram) Date: Fri, 15 Oct 1999 11:23:37 -0500 (CDT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dodge Ram said: > Hi, > > I am looking at ways to handle segV's gracefully without > letting a process die. I am aware of the siglongjmp() call and don't > know if that is the only way to handle segV's > > Any pointers on how to gracefully (?) handle segV and not > letting the process die will be of great help. > > Also, given that I have a solution to test, what are all the > ways I can ensure that my process handles segV's rightly ? > > thanks and regards, > > ramC > Attempting to recover from a SIGSEGV seems like a very risky proposition. Essentially, ANY writeable memory by the process may have been clobbered before the process decided to write to read-only memory generating the SIGSEGV. Suppose you recover and longjump somewhere and then flush your IO buffers out to disk. For all you know, the buffers are now total garbage, so now you have a running program working with incorrect data on disk. Yikes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message