libgcj/1307: Throwable.fillInStackTrace dumps core if backtrace fails

libgcj/1307: Throwable.fillInStackTrace dumps core if backtrace fails

[jsturm]

>Number:         1307
>Category:       libgcj
>Synopsis:       Throwable.fillInStackTrace dumps core if backtrace fails
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    aph
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:18:52 PST 2000
>Closed-Date:    Wed Jul 19 07:40:51 PDT 2000
>Last-Modified:  Wed Jul 19 07:50:00 PDT 2000
>Originator:     jsturm@detroit.appnet.com
>Release:        CVS trunk
>Organization:
>Environment:
alphapca56-unknown-linux-gnu
>Description:
Throwable.fillInStackTrace dies in an infinite loop if backtrace()
is not implemented.  On Alpha (and possibly others) backtrace
always returns zero, causing fillInStackTrace to call _Jv_NewPrimArray
with a size of -1, throwing a NegativeArraySizeException, calling
fillInStackTrace, repeat cycle until stack is exhausted.
>How-To-Repeat:
Run any program that throws an exception.
>Fix:
My workaround is to undef HAVE_BACKTRACE in config.h.  Either
autoconf could be enhanced to discover a non-functioning backtrace(),
or fillInStackTrace() can handle the zero return at runtime.
>Release-Note:

>Audit-Trail:

Formerly PR libgcj/286

Responsible-Changed-From-To: tromey->aph
Responsible-Changed-By: tromey
Responsible-Changed-When: Mon Jul 17 16:27:48 2000
Responsible-Changed-Why:
    Andrew handles backtraces.
    FWIW I think a runtime check would be best.

From: tromey@cygnus.com
To: aph@cygnus.com, java-gnats@sourceware.cygnus.com,
  jsturm@detroit.appnet.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/286
Date: 17 Jul 2000 23:27:48 -0000

 Synopsis: Throwable.fillInStackTrace dumps core if backtrace fails
 
 Responsible-Changed-From-To: tromey->aph
 Responsible-Changed-By: tromey
 Responsible-Changed-When: Mon Jul 17 16:27:48 2000
 Responsible-Changed-Why:
     Andrew handles backtraces.
     FWIW I think a runtime check would be best.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=286&database=java

From: Jeff Sturm <jeff.sturm@appnet.com>
To: java-gnats@sourceware.cygnus.com
Cc: aph@cygnus.com, tromey@cygnus.com
Subject: Re: libgcj/286
Date: Wed, 19 Jul 2000 10:09:59 -0400

 tromey@cygnus.com wrote:
 > FWIW I think a runtime check would be best.
 
 Agreed.  The obvious fix works for me:
 
 http://sources.redhat.com/ml/java-patches/2000-q3/msg00009.html
 
 --
 Jeff Sturm
 jeff.sturm@appnet.com
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Wed Jul 19 07:40:51 2000
State-Changed-Why:
    I checked in Jeff's fix for this.

From: tromey@cygnus.com
To: aph@cygnus.com, java-gnats@sourceware.cygnus.com,
  jsturm@detroit.appnet.com
Cc:  
Subject: Re: libgcj/286
Date: 19 Jul 2000 14:40:51 -0000

 Synopsis: Throwable.fillInStackTrace dumps core if backtrace fails
 
 State-Changed-From-To: open->closed
 State-Changed-By: tromey
 State-Changed-When: Wed Jul 19 07:40:51 2000
 State-Changed-Why:
     I checked in Jeff's fix for this.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=286&database=java
>Unformatted: