Re: java/5986: SIGSEGV in __gcj_personality_v0

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Bryce McKinlay]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, jsturm@one-point.com,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Thu, 21 Mar 2002 21:16:57 +1200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5986
 
 This test case works-for-me on both x86 and PPC:
 
 $ gcj CrashEH.java --main=CrashEH -O2
 $ ./a.out
 cleanup
 ok
 
 

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Jeff Sturm]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Jeff Sturm <jsturm@one-point.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Thu, 28 Mar 2002 20:16:15 -0500 (EST)

 On 28 Mar 2002, Tom Tromey wrote:
 > Jeff>  (Well, I had to use javac, since "gcj -C" caused verifier
 > Jeff>  errors... but's that's another problem.)
 > 
 > Verifier errors from gcj itself?
 
 Yes.
 
 > Unfortunately there are some known `gcj -C' bugs.  They're in Gnats.
 
 I figured that.  I really should find out whether this is a new problem.
 
 > I'm curious why you're compiling to bytecode first.
 
 Sometimes I don't (and couldn't until you fixed this PR).  Two reasons
 mainly:
 
 - I don't always have source
 
 - Compiling jars is incredibly convenient, I can do things like
 
 gcj -shared -O2 -fPIC -fjni /opt/oracle/jdbc/lib/classes111.zip \
 -o liborajdbc.so
 
 I haven't yet reworked our entire build process for gcj.  Someday maybe
 I'll autoconfiscate.
 
 Jeff
 

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Tom Tromey]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Jeff Sturm <jsturm@one-point.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: 28 Mar 2002 17:36:28 -0700

 Jeff>  I rebuilt the whole application from bytecode, 7 jar files
 Jeff>  containing some 1,018 class files... and it worked!
 
 Excellent.  I'll check it in at some point; we can always back it out
 or refine it if need be.
 
 Jeff>  (Well, I had to use javac, since "gcj -C" caused verifier
 Jeff>  errors... but's that's another problem.)
 
 Verifier errors from gcj itself?  Unfortunately there are some known
 `gcj -C' bugs.  They're in Gnats.  Fixing them looks complicated, and
 I haven't had time to delve into it recently.
 
 I'm curious why you're compiling to bytecode first.
 
 Tom

Re: java/5986: SIGSEGV in __gcj_personality_v0

[tromey]

Synopsis: SIGSEGV in __gcj_personality_v0

State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Thu Mar 28 16:41:31 2002
State-Changed-Why:
    I've checked in the fix.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5986

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Alexandre Petit-Bianco]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Jeff Sturm <jsturm@one-point.com>
Cc: Tom Tromey <tromey@redhat.com>, gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Thu, 28 Mar 2002 14:41:31 -0800 (PST)

 Jeff Sturm writes:
 
 > Thanks for the fix... it really helps.
 
 Then if we can't wait for Per's review, I think this should go in.
 
 Thank you,
 
 ./A

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Jeff Sturm]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Jeff Sturm <jsturm@one-point.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gcc-gnats@gcc.gnu.org, Alexandre Petit-Bianco <apbianco@redhat.com>
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Thu, 28 Mar 2002 17:02:55 -0500 (EST)

 On 27 Mar 2002, Tom Tromey wrote:
 > I've only tested this minimally.  Could you try it on your code?
 
 I rebuilt the whole application from bytecode, 7 jar files containing some
 1,018 class files... and it worked!  (Well, I had to use javac, since "gcj
 -C" caused verifier errors... but's that's another problem.)
 
 Thanks for the fix... it really helps.
 
 Jeff
 

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Tom Tromey]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: apbianco@redhat.com
Cc: Jeff Sturm <jsturm@one-point.com>, gcc-gnats@gcc.gnu.org,
        Per Bothner <per@bothner.com>
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: 27 Mar 2002 18:25:48 -0700

 Alex> Per would know better, but this looks like a sane thing to do.
 
 Per, could you look at the patch in PR 5986?
 I can email it to you if you want.
 
 Thanks,
 Tom

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Alexandre Petit-Bianco]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: tromey@redhat.com
Cc: Jeff Sturm <jsturm@one-point.com>, gcc-gnats@gcc.gnu.org,
        Alexandre Petit-Bianco <apbianco@redhat.com>
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Wed, 27 Mar 2002 16:24:37 -0800 (PST)

 Tom Tromey writes:
 
 > Alex, as always, I desire your input.
 
 Per would know better, but this looks like a sane thing to do.
 
 ./A

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Tom Tromey]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Jeff Sturm <jsturm@one-point.com>
Cc: gcc-gnats@gcc.gnu.org, Alexandre Petit-Bianco <apbianco@redhat.com>
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: 27 Mar 2002 16:39:29 -0700

 Jeff> Try this one.
 
 This patch fixes the problem for me.  I think the comment explains
 what is going on; if you think of a way to improve it let me know.
 
 I've only tested this minimally.  Could you try it on your code?
 
 Alex, as always, I desire your input.
 
 Tom
 
 Index: ChangeLog
 from  Tom Tromey  <tromey@redhat.com>
 
 	* except.c (expand_end_java_handler): If the handler type is NULL,
 	use java.lang.Throwable.  Fixes PR java/5986.
 
 Index: except.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/java/except.c,v
 retrieving revision 1.26
 diff -u -r1.26 except.c
 --- except.c 2001/03/28 11:01:47 1.26
 +++ except.c 2002/03/27 23:03:07
 @@ -1,5 +1,5 @@
  /* Handle exceptions for GNU compiler for the Java(TM) language.
 -   Copyright (C) 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
 +   Copyright (C) 1997, 1998, 1999, 2000, 2002 Free Software Foundation, Inc.
  
  This file is part of GNU CC.
  
 @@ -372,7 +372,17 @@
    expand_start_all_catch ();
    for ( ; handler != NULL_TREE; handler = TREE_CHAIN (handler))
      {
 -      expand_start_catch (TREE_PURPOSE (handler));
 +      /* For bytecode we treat exceptions a little unusually.  A
 +	 `finally' clause looks like an ordinary exception handler for
 +	 Throwable.  The reason for this is that the bytecode has
 +	 already expanded the finally logic, and we would have to do
 +	 extra (and difficult) work to get this to look like a
 +	 gcc-style finally clause.  */
 +      tree type = TREE_PURPOSE (handler);
 +      if (type == NULL)
 +	type = throwable_type_node;
 +
 +      expand_start_catch (type);
        expand_goto (TREE_VALUE (handler));
        expand_end_catch ();
      }

Re: java/5986: SIGSEGV in __gcj_personality_v0

[tromey]

Synopsis: SIGSEGV in __gcj_personality_v0

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Mar 27 15:05:53 2002
Responsible-Changed-Why:
    I'm handling this.
State-Changed-From-To: open->analyzed
State-Changed-By: tromey
State-Changed-When: Wed Mar 27 15:05:53 2002
State-Changed-Why:
    Patch written.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5986

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Tom Tromey]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Jeff Sturm <jsturm@one-point.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: 27 Mar 2002 14:59:53 -0700

 Jeff> Try this one.
 
 I've looked at this a little today.
 It looks like `finally' is miscompiled by the bytecode front end.
 Even this test fails for me when compiled from .class:
 
 public class CrashEH {
   public static void main (String[] args) throws Exception
   {
     try {
       throw new Exception();
     } finally {
       System.out.println("cleanup");
     }
   }
 }
 
 Tom

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Jeff Sturm]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Jeff Sturm <jsturm@one-point.com>
To: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Thu, 21 Mar 2002 09:38:03 -0500 (EST)

 On Thu, 21 Mar 2002, Bryce McKinlay wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5986
 > 
 > This test case works-for-me on both x86 and PPC:
 > 
 > $ gcj CrashEH.java --main=CrashEH -O2
 > $ ./a.out
 > cleanup
 > ok
 
 I apologize for the faulty instructions.  (Writing a good PR is hard!)
 
 Compile/run the example from bytecode:
 
 [jsturm@omega tmp]$ gcj CrashEH.class -o CrashEH --main=CrashEH
 [jsturm@omega tmp]$ ./CrashEH
 Segmentation fault
 
 It makes no difference whether I use javac or gcj -C to compile the 
 source.
 
 Jeff
 

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Jeff Sturm]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Jeff Sturm <jsturm@one-point.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: Wed, 20 Mar 2002 20:19:59 -0500 (EST)

 On 20 Mar 2002, Tom Tromey wrote:
 > I can't find the attachment.
 > Could you send the program?
 
 Try this one.
 
 public class CrashEH {
   public void t() throws Exception {
     try {
       try {
         throw new Exception();
       } catch (Exception e) {
         throw e;
       }
     } finally {
       System.out.println("cleanup");
     }
   }
   public static void main(String[] args) {
     try {
       (new CrashEH()).t();
     } catch (Exception ex) {
       System.out.println("ok");
     }
   }
 }
 

Re: java/5986: SIGSEGV in __gcj_personality_v0

[Tom Tromey]

The following reply was made to PR java/5986; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: jsturm@one-point.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5986: SIGSEGV in __gcj_personality_v0
Date: 20 Mar 2002 17:10:48 -0700

 >>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
 
 Jeff> The attached program fails when compiled from bytecode.
 Jeff> Compiling from source works as expected.
 
 I can't find the attachment.
 Could you send the program?
 
 Tom

java/5986: SIGSEGV in __gcj_personality_v0

[jsturm]

>Number:         5986
>Category:       java
>Synopsis:       SIGSEGV in __gcj_personality_v0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 17 07:16:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Jeff Sturm
>Release:        gcc version 3.1 20020316 (prerelease)
>Organization:
>Environment:
Reading specs from /opt/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../configure --prefix=/opt/gcc --enable-languages=c++,java --enable-threads : (reconfigured)  : (reconfigured)  : (reconfigured)  : (reconfigured)  : (reconfigured) 
Thread model: posix
>Description:
The attached program fails when compiled from bytecode.  Compiling from source works as expected.

This appears to be a new problem rather than a regression... 3.0.4 exhibits the same behavior.

I entered this as a frontend bug since the indications are that gcj is emitting either bad code or wrong unwind info.
>How-To-Repeat:
gcj -C CrashEH.java
gcj CrashEH.java --main=CrashEH -o CrashEH
./CrashEH
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: