Re: Use of alternate stack for signal handler
- From: Robert Redelmeier <redelm@xxxxxxxxxxxxxxx>
- Date: Fri, 30 Dec 2005 16:04:16 GMT
Kasper Dupont <57203463996516718595@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> limit the stack cannot grow forever before hitting
The classic heap/stack collision.
> should stop doing it, if the extra page would cause the
> stack to touch another mapping. I haven't tested that,
> but I'm going to do so.
A worthwhile experiment. Please report back.
> If you overflow a kernel stack, you are going to corrupt
> kernel data structures. This may lead to strange problems.
> A way to detect stack overflows in the kernel would be
> convenient for debuging (it probably has been done).
Ouch! I would hope that the kernel bottom-of-stack [limit]
would have a marker (0xDEADBEEF is classic) to show if
it had been trampled.
> Threads share the same address space.
Sure! But fork() and friends had better separate[CoW] their
stacks lest function calls (especially blocking syscalls)
do wierd and wonderous things :)
-- Robert
>
.
- References:
- Use of alternate stack for signal handler
- From: Madhav
- Re: Use of alternate stack for signal handler
- From: Robert Redelmeier
- Use of alternate stack for signal handler
- Prev by Date: Re: Use of alternate stack for signal handler
- Next by Date: Re: to enable C or C++ syntax highlighting in Vi Editor
- Previous by thread: Re: Use of alternate stack for signal handler
- Index(es):
Relevant Pages
|
