Date: Wed, 19 Feb 2003 08:51:23 -0800 From: Wes Peters <wes@softweyr.com> To: Vaclav Haisman <V.Haisman@sh.cvut.cz>, Terry Lambert <tlambert2@mindspring.com> Cc: Vaclav Haisman <V.Haisman@sh.cvut.cz>, <freebsd-hackers@freebsd.org> Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop Message-ID: <200302190851.23498.wes@softweyr.com> In-Reply-To: <20030219134131.T70370-100000@logout.sh.cvut.cz> References: <20030219134131.T70370-100000@logout.sh.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 19 February 2003 04:43, Vaclav Haisman wrote:
> > man 2 abort
> >
> > -- Terry
>
> logout ~/tmp>man 2 abort
> No entry for abort in section 2 of the manual
Yeah, it's in (3). try _exit(2).
> Besides, this doesn't explain anything. I see I haven't asked any
> question in my previous post. So, why does FreeBSD behave different?
Because it *is* different? If you want to catch a signal and be
able to handle it, the other two are wrong, are they not?
The idea here is to catch SEGV and be able to respond to it in some
reasonable fashion. What that reasonable fashion might be is left
up to the program, that's why we have signal handlers. You might
for instance want to close open files or disconnect from a database
connection. What if the file close or database socket close yeilds
another SEGV? Do you want to just abruptly die, or do you want to
at least be able to attempt to log this condition? You can always
count the number of SEGVs you've handled with a static counter and
modify your behavior accordingly.
What would you like to see, a sigaction flag of SA_CRASHON2NDSIG that
is set by default? (Ah, Wes, that software comedian.)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302190851.23498.wes>