> 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();
<QUOTE>
RLIMIT_STACK
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.
</QUOTE>
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
sufficient...?
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/