This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

idea for StackOverflowException


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]