libgcj/1310: exit value after uncatched exception should be non-zero

[osk at hem dot passagen dot se]

>Number:         1310
>Category:       libgcj
>Synopsis:       exit value after uncatched exception should be non-zero
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tromey
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:18:55 PST 2000
>Closed-Date:    Tue Sep 12 23:38:10 PDT 2000
>Last-Modified:  Wed Sep 13 08:00:00 PDT 2000
>Originator:     osk@hem.passagen.se
>Release:        unknown-1.0
>Organization:
>Environment:
libgcj 2000-07-18
>Description:
When a program exits because of an uncatched exception,
the exit value should be non-zero. Programs compiled
with gcj returns with 0 with an exception is thrown,
and the same applies for gij.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Formerly PR libgcj/289


From: Tom Tromey <tromey@cygnus.com>
To: osk@hem.passagen.se
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/289: exit value after uncatched exception should be non-zero
Date: Wed, 19 Jul 2000 07:26:16 -0700 (PDT)

 Oskar> When a program exits because of an uncatched exception,
 Oskar> the exit value should be non-zero. Programs compiled
 Oskar> with gcj returns with 0 with an exception is thrown,
 Oskar> and the same applies for gij.
 
 Unfortunately this looks hard to fix.  Suppose there are two threads
 and one exits this way and the other exits normally?  I guess we could
 add a special case when there is a single thread.
 
 Tom
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Sun Sep 10 22:06:06 2000
State-Changed-Why:
    See appended email

From: tromey@cygnus.com
To: java-gnats@sourceware.cygnus.com, osk@hem.passagen.se, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/289
Date: 11 Sep 2000 05:06:06 -0000

 Synopsis: exit value after uncatched exception should be non-zero
 
 State-Changed-From-To: open->feedback
 State-Changed-By: tromey
 State-Changed-When: Sun Sep 10 22:06:06 2000
 State-Changed-Why:
     See appended email
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=289&database=java

From: Tom Tromey <tromey@cygnus.com>
To: osk@hem.passagen.se
Cc: Java Gnats Server <java-gnats@sourceware.cygnus.com>
Subject: libgcj/289
Date: 10 Sep 2000 23:18:22 -0600

 I've investigated this some more.
 
 I experimented with the JDK.  With the JDK interpreter, if the main
 thread throws an uncaught exception and then exits (because that was
 the last thread) then the runtime with exit with status 1.
 
 But consider the appended program.  This program attempts to determine
 what happens if the main thread throws an exception but is not the
 last thread to stop.  In this situation, what should happen?  I don't
 know, because the JDK hangs.  (Maybe there is a bug in my test, feel
 free to enlighten me.)
 
 I don't think we should do anything special here.  I agree it is less
 than perfect, but it isn't clear what the right thing is, and
 compatibility with the JDK seems hard.
 
 If the situation changes wrt the JDK, feel free to reopen the PR.  We
 can always address it later.
 
 Tom
 
 public class q implements Runnable
 {
   public static Thread t_bad, t_good;
 
 
   public boolean bad_flag;
 
   public void run () throws InterruptedException
   {
     if (bad_flag)
       {
 	throw new NullPointerException ("zardoz!");
       }
     else
       {
 	t_bad.join ();
       }
   }
 
   public q (boolean x)
   {
     bad_flag = x;
   }
 
   public static void main (String[] args) throws InterruptedException
   {
     q t1 = new q (true);
     q t2 = new q (false);
 
     t_bad = Thread.currentThread ();
     t_good = new Thread (t2);
     t_good.start ();
     t1.run ();
   }
 }

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/289
Date: Mon, 11 Sep 2000 20:05:45 +1200

 Tom Tromey wrote:
 
 >  I experimented with the JDK.  With the JDK interpreter, if the main
 >  thread throws an uncaught exception and then exits (because that was
 >  the last thread) then the runtime with exit with status 1.
 >
 >  But consider the appended program.  This program attempts to determine
 >  what happens if the main thread throws an exception but is not the
 >  last thread to stop.  In this situation, what should happen?  I don't
 >  know, because the JDK hangs.  (Maybe there is a bug in my test, feel
 >  free to enlighten me.)
 
 Interesting. It seems that in the JDK, a join() on a thread that throws an
 unchecked exception never returns. This behaviour seems reasonable, I guess,
 as a thread that throws an exception could potentially leave objects in an
 unstable state. This is consistent across several different JDK versions (and
 combinations of green/native threads), so perhaps we should look at
 duplicating it.
 
 >  I don't think we should do anything special here.  I agree it is less
 >  than perfect, but it isn't clear what the right thing is, and
 >  compatibility with the JDK seems hard.
 
 If any thread throws unchecked, the JDK will exit with status 1 once the last
 thread dies, unless another thread specifically calls System.exit() with a
 different exit status. It should just be a matter of setting an error flag
 somewhere and checking it in the exit routine.
 
 >  public class q implements Runnable
 >  {
 >    public static Thread t_bad, t_good;
 >
 >
 >    public boolean bad_flag;
 >
 >    public void run () throws InterruptedException
 
 There is a compiler bug here - this declaration should be illegal because
 run() in Runnable does not throw InterruptedException. I can't duplicate this
 for any class/interface other than Runnable, however. Strange.
 
 regards
 
   [ bryce ]
 
 
State-Changed-From-To: feedback->closed
State-Changed-By: bryce
State-Changed-When: Tue Sep 12 23:38:10 2000
State-Changed-Why:
    I checked in a fix. libgcj should now match the JDK.

From: bryce@albatross.co.nz
To: java-gnats@sourceware.cygnus.com, osk@hem.passagen.se, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/289
Date: 13 Sep 2000 06:38:10 -0000

 Synopsis: exit value after uncatched exception should be non-zero
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bryce
 State-Changed-When: Tue Sep 12 23:38:10 2000
 State-Changed-Why:
     I checked in a fix. libgcj should now match the JDK.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=289&database=java

From: Tom Tromey <tromey@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/289
Date: 13 Sep 2000 09:05:00 -0600

 Bryce> Interesting. It seems that in the JDK, a join() on a thread
 Bryce> that throws an unchecked exception never returns. This
 Bryce> behaviour seems reasonable, I guess, as a thread that throws an
 Bryce> exception could potentially leave objects in an unstable
 Bryce> state. This is consistent across several different JDK versions
 Bryce> (and combinations of green/native threads), so perhaps we
 Bryce> should look at duplicating it.
 
 This behavior seems broken to me.  If I'm trying to join() a thread, I
 probably don't care how the thread exited -- just that it did.  If we
 follow the Sun implementation then a join() of an
 abnormally-terminated thread will just cause the runtime to hang.
 This seems losing.
 
 Tom
>Unformatted: