This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
libgcj/1475: GC causes core dump in gcj-compiled programs
- To: java-gnats at sourceware dot cygnus dot com
- Subject: libgcj/1475: GC causes core dump in gcj-compiled programs
- From: jsturm at sigma6 dot com
- Date: 5 Nov 1999 22:02:40 -0000
- Reply-To: jsturm at sigma6 dot com
>Number: 1475
>Category: libgcj
>Synopsis: core dump in gcj-compiled programs on Linux/Alpha
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tromey
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:20:33 PST 2000
>Closed-Date: Fri Apr 21 20:39:59 PDT 2000
>Last-Modified: Fri Apr 21 22:16:01 PDT 2000
>Originator: Jeff Sturm
>Release: current cvs
>Organization:
>Environment:
linux (alpha)
>Description:
Programs compiled with current libgcj dump core sometime
after garbage collection. The program:
public class HeapTest {
public static void main(String[] args) {
java.util.Random generator = new java.util.Random();
Runtime runtime = Runtime.getRuntime();
System.out.println("free memory = " + runtime.freeMemory());
System.out.println("total memory = " + runtime.totalMemory());
for (int n = 0; n < 10000; n++) {
byte[] junk = new byte[(generator.nextInt() & 0x7fffffff) % 512];
}
runtime.gc();
System.out.println("free memory = " + runtime.freeMemory());
System.out.println("total memory = " + runtime.totalMemory());
}
}
fails in the final println():
(gdb) run
Starting program: /home/jsturm/tmp/heaptest
free memory = 8192
total memory = 131072
Program received signal SIGSEGV, Segmentation fault.
0x400a74f0 in java::io::PrintStream::writeChars (this=@8061d80, str=@8064f18,
offset=0, count=21)
at ../../../libgcj-current/libjava/java/io/PrintStream.java:123
123 if (out.count + count >= out.buf.length)
>How-To-Repeat:
Run the above program.
>Fix:
>Release-Note:
>Audit-Trail:
Formerly PR libgcj/93
From: Bryce McKinlay <bryce@albatross.co.nz>
To: jsturm@sigma6.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/93: GC causes core dump in gcj-compiled programs
Date: Sat, 06 Nov 1999 14:29:39 +1300
jsturm@sigma6.com wrote:
> >Description:
> Programs compiled with current libgcj dump core sometime
> after garbage collection. The program:
I can't reproduce this here using the latest libgcj compiled with gcc 2.95.2.
This looks like the weird problems I was having with the recent experimental
gcc's - I don't think it is directly related to the gc.
Try a different version of gcc and it should work fine.
regards
[ bryce ]
From: Tom Tromey <tromey@cygnus.com>
To: jsturm@sigma6.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/93: GC causes core dump in gcj-compiled programs
Date: Fri, 12 Nov 1999 20:49:37 -0800 (PST)
FWIW, this doesn't happen to me with my current build.
Does it still happen for you?
(Offhand I don't recall how old my gcc is. Maybe that has some effect.)
T
From: Jeff Sturm <jsturm@sigma6.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/93: GC causes core dump in gcj-compiled programs
Date: Sat, 13 Nov 1999 10:23:13 -0500 (EST)
On Fri, 12 Nov 1999, Tom Tromey wrote:
> FWIW, this doesn't happen to me with my current build.
> Does it still happen for you?
> (Offhand I don't recall how old my gcc is. Maybe that has some effect.)
Probably. I was using the gcc trunk. Perhaps I should have filed the PR
for gcj.
As a workaround I commented out all the marking code in libjava/boehm.cc,
so the GC scans all Java objects conservatively. My tests ran fine
afterwards. This suggests that something was wrong in reflection, on
which the marking code depends. So perhaps something changed in the class
layout, or gcj is really generating incorrect code... I'm not sure.
Jeff
State-Changed-From-To: open->analyzed
State-Changed-By: green
State-Changed-When: Sun Jan 16 12:32:36 2000
State-Changed-Why:
I've added your test case to the testing harness.
Could you please try it again. Maybe something important
has been fixed.
From: green@cygnus.com
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/93
Date: 16 Jan 2000 20:32:36 -0000
Synopsis: GC causes core dump in gcj-compiled programs
State-Changed-From-To: open->analyzed
State-Changed-By: green
State-Changed-When: Sun Jan 16 12:32:36 2000
State-Changed-Why:
I've added your test case to the testing harness.
Could you please try it again. Maybe something important
has been fixed.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=93&database=java
From: Bryce McKinlay <bryce@albatross.co.nz>
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/93
Date: Mon, 06 Mar 2000 13:05:10 +1300
I think we can we close this PR. The test case does not fail for me with
the current gcj/libgcj. Jeff, can you verify?
regards
[ bryce ]
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=93&database=java
From: Jeff Sturm <jsturm@sigma6.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Subject: Re: libgcj/93
Date: Mon, 06 Mar 2000 12:07:16 -0500
Bryce McKinlay wrote:
> I think we can we close this PR. The test case does not fail for me with
> the current gcj/libgcj. Jeff, can you verify?
It may be platform dependent. I originally observed the core dump on
x86, but that does seem to have been fixed... more recently it has been
a problem on Alpha. I really don't know why. It could be a compiler
bug. GC problems can be notoriously difficult to debug.
--
Jeff Sturm
jsturm@sigma6.com
From: Bryce McKinlay <bryce@albatross.co.nz>
To: Jeff Sturm <jsturm@sigma6.com>
Cc: tromey@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/93
Date: Tue, 07 Mar 2000 13:07:45 +1300
Jeff Sturm wrote:
> Bryce McKinlay wrote:
> > I think we can we close this PR. The test case does not fail for me with
> > the current gcj/libgcj. Jeff, can you verify?
>
> It may be platform dependent. I originally observed the core dump on
> x86, but that does seem to have been fixed... more recently it has been
> a problem on Alpha. I really don't know why. It could be a compiler
> bug. GC problems can be notoriously difficult to debug.
Thanks. I have updated the Synopsis of this PR to reflect this.
regards
[ bryce ]
State-Changed-From-To: analyzed->feedback
State-Changed-By: tromey
State-Changed-When: Fri Apr 21 07:33:23 2000
State-Changed-Why:
Hi Jeff.
Could you take another look at this PR?
Bryce imported the latest Boehm GC, which includes
an important GC bug fix for the alpha. It is possible
that this problem was caused by that bug.
If it still fails for you with the new GC, tell me
and I will reopen this PR.
From: tromey@cygnus.com
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/93
Date: 21 Apr 2000 14:33:23 -0000
Synopsis: core dump in gcj-compiled programs on Linux/Alpha
State-Changed-From-To: analyzed->feedback
State-Changed-By: tromey
State-Changed-When: Fri Apr 21 07:33:23 2000
State-Changed-Why:
Hi Jeff.
Could you take another look at this PR?
Bryce imported the latest Boehm GC, which includes
an important GC bug fix for the alpha. It is possible
that this problem was caused by that bug.
If it still fails for you with the new GC, tell me
and I will reopen this PR.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=93&database=java
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: libgcj/93
Date: Fri, 21 Apr 2000 10:00:43 -0700 (PDT)
tromey@cygnus.com writes:
> Hi Jeff. Could you take another look at this PR? Bryce
> imported the latest Boehm GC, which includes an important GC
> bug fix for the alpha. It is possible that this problem was
> caused by that bug. If it still fails for you with the new GC,
> tell me and I will reopen this PR.
I'm also guessing that (initialized upon declaration) arrays with 2+
dimensions aren't really working. This patch might help.
./A
2000-04-05 Alexandre Petit-Bianco <apbianco@cygnus.com>
* class.c (build_java_array_type): `data' to always use pointer
alignment.
Index: typeck.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/java/typeck.c,v
retrieving revision 1.51
diff -u -p -r1.51 typeck.c
--- typeck.c 2000/03/13 19:42:33 1.51
+++ typeck.c 2000/04/06 01:44:57
@@ -417,6 +417,7 @@ build_java_array_type (element_type, len
{
tree atype = build_prim_array_type (element_type, length);
tree arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
+ TYPE_ALIGN (atype) = TYPE_ALIGN (ptr_type_node);
DECL_CONTEXT (arfld) = t;
TREE_CHAIN (fld) = arfld;
State-Changed-From-To: feedback->closed
State-Changed-By: tromey
State-Changed-When: Fri Apr 21 20:39:59 2000
State-Changed-Why:
Jeff reports this is fixed.
From: Jeff Sturm <jsturm@sigma6.com>
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/93
Date: Fri, 21 Apr 2000 23:45:01 -0400
I think we're OK now. With the new GC I can run Kaffe's GCTest.java
without failure. The new compiler may have helped too.
Interestingly it had worked all along if I reverted to conservative
marking. It was the precise object marking in boehm.cc that failed, but
it works now.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=93&database=java
--
Jeff Sturm
jsturm@sigma6.com
From: tromey@cygnus.com
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/93
Date: 22 Apr 2000 03:39:59 -0000
Synopsis: core dump in gcj-compiled programs on Linux/Alpha
State-Changed-From-To: feedback->closed
State-Changed-By: tromey
State-Changed-When: Fri Apr 21 20:39:59 2000
State-Changed-Why:
Jeff reports this is fixed.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=93&database=java
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: libgcj/93
Date: Fri, 21 Apr 2000 22:05:35 -0700 (PDT)
Jeff Sturm writes:
> I think we're OK now. With the new GC I can run Kaffe's
> GCTest.java without failure. The new compiler may have helped too.
Speaking of which, I'd be interested to know if you can use array
featuring 2 or more dimensions? Something like:
int x[][] = {{1,2},{3,4}};
...
for (int i = 0; i < x.length; i++)
for (int j = 0; j < x[i].length; j++)
System.out.println ("x["+i+"]["+j+"]="+x[i][j]);
If this doesn't work, I posted a patch that I'd like you to try.
Thanks,
./A
>Unformatted: