[commit-cp] [bugs #10869] Threadgroup.uncaughtException shouldn't catch exceptions

[David Holmes]

This mail is an automated notification from the bugs tracker
 of the project: classpath.




/**************************************************************************/
[bugs #10869] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10869>
Project: classpath
Submitted by: David Holmes
On: Tue 11/02/2004 at 07:04

Category:  classpath
Severity:  5 - Average
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Platform Version:  None


Summary:  Threadgroup.uncaughtException shouldn't catch exceptions

Original Submission:  Threadgroup.uncaughtException essentially does this:

try
          {
            if (thread != null)
              System.err.print("Exception in thread "" + thread.name + "" ");
            t.printStackTrace(System.err);
          }
        catch (Throwable x)
          {
            // This means that something is badly screwed up with the runtime,
            // or perhaps someone overloaded the Throwable.printStackTrace to
            // die. In any case, try to deal with it gracefully.
            try
              {
                System.err.println(t);
                System.err.println("*** Got " + x
                                   + " while trying to print stack trace.");
              }
            catch (Throwable x2)
              {
                // Here, someone may have overloaded t.toString() or
                // x.toString() to die. Give up all hope; we can't even chain
                // the exception, because the chain would likewise die.
                System.err.println("*** Catastrophic failure while handling "
                                   + "uncaught exception.");
                throw new InternalError();
              }
          }
      }

These secondary catches should not be present. Any exceptions that happen to 
occur during the attempt to handle the uncaught exception should simply be 
allowed to propogate. The VM has responsibility for invoking uncaughtException 
and thus handling, or ignoring any exceptions generated from it.

Consider for example, if the uncaught exception is OutOfMemoryError - all these 
attempts to handle it will simply trigger more and more OutOfMemoryError 
conditions. Such conditions should not pollute System.err with these extra 
"debug" like messages, nor should the exception be converted to an 
internalError. In the latter case if throwing internalError "succeeds" then all 
you have done is mask what really went wrong.

Keep it simple: uncaught exception should just attempt to print the stack trace 
and nothing else.

For the record this is biting me in a Realtime JVM using RTSJ ScopedMemory, 
where OutOfMemoryError (OOME)leading to abrupt thread termination is quite easy 
to trigger. I handle the OOME in the caller of UncaughtException but a better 
solution is to re-write UncaughtException to be more OOME aware.











For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10869>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/