lkml.org 
[lkml]   [2004]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] signal handler defaulting fix ...
On Tue, 29 June 2004 03:24:41 +0200, Edgar Toernig wrote:
> Linus Torvalds wrote:
> >
> > So? That program is buggy.
>
> Not the signal part. It was written for libc5. There, signals set
> with signal(2) were reset when raised (SysV-style). Leaving such a
> signal handler with longjmp was perfectly valid.

But has a very distinct problem. A segmentation fault is usually a
bug and deserves a core dump. Sane default behaviour. If the program
tells the kernel, it can handle segmentation faults on it's own, fine.
But if - while handling the fault - it creates a second one, the claim
was obviously false. Coredump, done.

Now, how can the kernel tell, whether a second segmentation fault
happened inside the handler or after successfully handling the first
one? Right, with longjmp it can't. Coredump, done.

Jörn

--
Victory in war is not repetitious.
-- Sun Tzu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.051 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site