This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
idea for StackOverflowException
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- To: Adam Megacz <gcj at lists dot megacz dot com>
- Cc: java at gcc dot gnu dot org
- Date: Fri, 28 Dec 2001 07:28:57 +0000 (GMT)
- Subject: idea for StackOverflowException
- References: <86k7v7de9j.fsf@megacz.com>
Adam Megacz writes:
>
> As I recall, the major impediment to implementing
> StackOverflowException is having to call new from within the
> stack-overflow signal handler -- at that point, you have no stack
> left with which to call StackOverflow's constructor.
>
> How about this: in Thread.start(), scan the stack area by writing to
> each location, in progressively increasing until you get a stack
> overflow signal (for speed, consider an exponentially increasing
> search, followed by a binary search). Then, write-protect the top page
> of the stack. When a write to the top page is detected, throw a
That's how linuxthreads detects a stack overflow.
> StackOverflowException and allow writes to the top page until the
> exception is caught.
>
> That way, you never have to attempt to throw an exception or call new
> from inside the stack overflow signal handler.
>
> Would this work?
No. You need to signal the exception on a separate stack because the
kernel itself needs a stack while delivering the signal.
This is what happens:
Enter a function. Save a register on the stack.
---> Write to protected page, causing a fault.
---> Enter the kernel's fault handler.
---> Kernel tries to deliver SEGV.
Kernel pushes the user's registers onto the stack.
---> Write to protected page, causing a fault while
delivering the signal.
---> Kernel kills the process.
That's why you need sigaltstack().
Andrew.