bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug classpath/22794] New: Threadgroup.uncaughtException shouldn't catch


From: pinskia at gcc dot gnu dot org
Subject: [Bug classpath/22794] New: Threadgroup.uncaughtException shouldn't catch exceptions
Date: 1 Oct 2005 17:27:19 -0000

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.
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-03 00:34 -------
Here is how I have rewritten uncaughtException to not perform any direct 
allocation and to be more resilient to OutOfMemory conditions:



  public void uncaughtException(Thread thread, Throwable t) {

      if (parent != null)

          parent.uncaughtException(thread, t);

      else if (!(t instanceof ThreadDeath)) {

              had_uncaught_exception = true; // this makes little sense!



              // avoid all allocation and catch any cascading OOME's

              String name = INDETERMINATE;

              try {

                  name = thread.getName();

              }

              catch (OutOfMemoryError oome) {

              }

              System.err.print(MSG1);

              System.err.print(name);

              System.err.print(MSG2);

              try {

                  // We could do this in a temporary scope, but there's no 

                  // guarantee about the size of scope we would need, nor can we

                  // be sure some custom exception object doesn't have a bad

                  // implementation that will throw an exception that would then

                  // try to exit the scope. Simpler just to let this fail.

                  t.printStackTrace(System.err);

              }

              catch (OutOfMemoryError oome) {

                  String throwable = null;

                  try {

                      throwable = t.toString();

                  }

                  catch (OutOfMemoryError oome2) {

                      if (t instanceof OutOfMemoryError)

                          throwable = OOME;

                      else

                          throwable = INDETERMINATE;

                  }

                  System.err.print(throwable);

                  System.err.println(NOSTACK);

              }

      }

  }





    static final String MSG1 = "Exception in thread \"";

    static final String MSG2 = "\": ";

    static final String INDETERMINATE = "<indeterminate>";

    static final String OOME = "OutOfMemoryError";

    static final String NOSTACK = "\t<No stack trace available>";


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:27 -------
Confirmed.

-- 
           Summary: Threadgroup.uncaughtException shouldn't catch exceptions
           Product: classpath
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P3
         Component: classpath
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: from-classpath at savannah dot gnu dot org
                CC: bug-classpath at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22794




reply via email to

[Prev in Thread] Current Thread [Next in Thread]