[lkml]   [1999]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.2.1: memory corruption and SIGSEGV handlers.

> I don't see the program hanging. Instead, I see it looping, using
> about 50% of the available CPU. It is still responsive to ^C, etc.
> This is what I would expect because you are trying to produce a
> double-fault and the kernel won't let you do this. However, you
> have prevented the kernel from using its normal fault-handler, so
> what would you expect? The program appears to perform exactly
> as coded. If there is no signal-stack, you don't get a signal.
> You deliberately used your signal stack via recursion and you
> have no trap to force an exit so what you see is what you get.

From the Single Unix Specification, Version 2, getrlimit();

This is the maximum size of a process' stack in bytes. The
implementation will not automatically grow the stack beyond this limit. If
this limit is exceeded, SIGSEGV is generated for the thread. If the thread
is blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and
has not made arrangements to use an alternate stack, the disposition of
SIGSEGV will be set to SIG_DFL before it is generated.

Tigran was catching SIGSEGV (ie. has a handler), and there was no
alternative stack. Linux isn't setting the disposition of SIGSEGV for
an exceeded stack to SIG_DFL. Hence the looping, and the breaking of the
standard. At least that's how I read it, I could be wrong....

Simply loosening the condition under the give_sigsegv label, where the
handler is set to SIG_DFL, in setup_frame()/setup_rt_frame() should be


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.039 / U:2.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site