This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: PR java/1373: recursion stress test causes segmentation fault
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "David Daney" <ddaney at avtrex dot com>
- Cc: "Andrew Haley" <aph at redhat dot com>,"Anthony Green" <green at redhat dot com>, <java-patches at gcc dot gnu dot org>
- Date: Thu, 21 Oct 2004 13:37:28 -0700
- Subject: RE: PR java/1373: recursion stress test causes segmentation fault
> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org
> [mailto:java-patches-owner@gcc.gnu.org]On Behalf Of David Daney
> Sent: Thursday, October 21, 2004 12:04 PM
> To: Boehm, Hans
> Cc: Andrew Haley; Anthony Green; java-patches@gcc.gnu.org
> Subject: Re: PR java/1373: recursion stress test causes segmentation
> fault
>
> The trusted library author should put try{} finally{} around
> anything that
> is critical. Although the things in the finally block should
> probably not
> make any method calls as that could trigger another
> StackOverflowError...
>
That sounds pretty hopeless to me. You would have to be able to
recover at least from every state that could exist at a method
call and return data structures to a consistent state. The same
would have to be true for every data structure that might
be used and relied upon by trusted code.
OutOfMemoryError actually has a lot of the same problems, already.
Looking at some of the simpler java.util code (LinkedList, Vector),
even an OutOfMemoryError can corrupt the data structures. :-(