libgcj/1446: Core dump of simple application
dey@nc.fnc.fujitsu.com
dey@nc.fnc.fujitsu.com
Wed Dec 20 12:27:00 GMT 2000
>Number: 1446
>Category: libgcj
>Synopsis: Solaris Linker Bug (Core dump of simple application)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tromey
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:19:58 PST 2000
>Closed-Date: Thu Jun 22 16:49:46 PDT 2000
>Last-Modified: Thu Jun 22 16:50:01 PDT 2000
>Originator: dey@nc.fnc.fujitsu.com
>Release: gcj 2.95.1
>Organization:
>Environment:
Solaris 2.7; SPARC Ultra 30; 256MB ram; Posix threads; Boehm GC.
>Description:
Running a simple application compiled using gcj results in a SIGSEGV while in the GC.
Here's the stack trace from gdb:
(gdb) run
Starting program: /tmp/rocky
[New LWP 2 ]
[New LWP 3 ]
Program received signal SIGSEGV, Segmentation fault.
0xff120e4c in GC_find_limit (p=0xffbef244 "", up=1)
at ../../../libgcj-2.95.1/boehm-gc/os_dep.c:681
681 GC_noop1((word)(*result));
(gdb) where
#0 0xff120e4c in GC_find_limit (p=0xffbef244 "", up=1)
at ../../../libgcj-2.95.1/boehm-gc/os_dep.c:681
#1 0xff120eac in GC_get_stack_base ()
at ../../../libgcj-2.95.1/boehm-gc/os_dep.c:723
#2 0xff11ffe4 in GC_init_inner ()
at ../../../libgcj-2.95.1/boehm-gc/misc.c:457
#3 0xff11cecc in GC_generic_malloc_inner (lb=2052, k=0)
at ../../../libgcj-2.95.1/boehm-gc/malloc.c:91
#4 0xff2bc164 in _Jv_InitGC () at ../../../libgcj-2.95.1/libjava/boehm.cc:335
#5 0xff2a7ae0 in _Jv_RegisterClasses (classes=0xffbef480)
at ../../../libgcj-2.95.1/libjava/java/lang/natClass.cc:582
#6 0xff2a7b6c in _Jv_RegisterClass (klass=0x290cc)
at ../../../libgcj-2.95.1/libjava/java/lang/natClass.cc:602
#7 0x14060 in global constructors keyed to Rocky.Rocky () at Rocky.java:6
#8 0x180b8 in __do_global_ctors_aux () at include/new:39
#9 0x180f0 in _init () at include/new:39
GCJ was built with the following flags:
--enable-fast-character --enable-threads=posix
POSIX threads were also specified when building gcc (2.95.1).
>How-To-Repeat:
Compile and run the following program thusly:
gcj -g -o rocky --main=Rocky Rocky.java -lposix4
public final class Rocky {
public static void main(String argv[])
{
System.out.println("Rocket J. Squirrel");
}
}
>Fix:
Switching to the Multi-language libtool should fix this,
and give us a working libgcj with the native linker on
solaris.
>Release-Note:
>Audit-Trail:
Formerly PR libgcj/67
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: apbianco
Responsible-Changed-When: Sun Nov 7 23:42:01 1999
Responsible-Changed-Why:
I changed the category and the person responsible.
Have you tried again recently?
From: apbianco@cygnus.com
To: apbianco@cygnus.com, dey@nc.fnc.fujitsu.com,
java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:
Subject: Re: libgcj/67
Date: 8 Nov 1999 07:42:01 -0000
Synopsis: Core dump of simple application
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: apbianco
Responsible-Changed-When: Sun Nov 7 23:42:01 1999
Responsible-Changed-Why:
I changed the category and the person responsible.
Have you tried again recently?
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=67
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Mon Nov 8 09:13:14 1999
State-Changed-Why:
This is probably not a GC problem at all. I imagine you
can "cont" past the apparent GC SEGV to find the real SEGV.
In some situations the GC causes SEGVs on purpose, and then
traps them to get information (for instance it does this
when finding stack limits).
Instead I imagine this is the Solaris linker bug.
You have to use the latest GNU ld with libgcj.
This has been hashed out several times on the list,
and is probably mentioned in the FAQ (though I'm not
positive).
Please get back to me on this so I can close the PR
or investigate more fully.
From: tromey@cygnus.com
To: dey@nc.fnc.fujitsu.com, java-gnats@sourceware.cygnus.com,
tromey@cygnus.com
Cc:
Subject: Re: libgcj/67
Date: 8 Nov 1999 17:13:14 -0000
Synopsis: Core dump of simple application
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Mon Nov 8 09:13:14 1999
State-Changed-Why:
This is probably not a GC problem at all. I imagine you
can "cont" past the apparent GC SEGV to find the real SEGV.
In some situations the GC causes SEGVs on purpose, and then
traps them to get information (for instance it does this
when finding stack limits).
Instead I imagine this is the Solaris linker bug.
You have to use the latest GNU ld with libgcj.
This has been hashed out several times on the list,
and is probably mentioned in the FAQ (though I'm not
positive).
Please get back to me on this so I can close the PR
or investigate more fully.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=67
From: David Young <dey@nc.fnc.fujitsu.com>
To: tromey@cygnus.com
Cc: java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Subject: Re: libgcj/67
Date: Mon, 8 Nov 1999 12:58:33 -0500 (EST)
>>>>> "tromey" == tromey <tromey@cygnus.com> writes:
tromey> Instead I imagine this is the Solaris linker bug. You
tromey> have to use the latest GNU ld with libgcj. This has been
tromey> hashed out several times on the list, and is probably
tromey> mentioned in the FAQ (though I'm not positive).
I'll try this suggestion and keep you folks apprised. Thanks much.
Regards,
--
-------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(dey@nc.fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
State-Changed-From-To: feedback->open
State-Changed-By: bryce
State-Changed-When: Wed Jun 7 00:22:32 2000
State-Changed-Why:
This is presumed to be the solaris native-linker bug, which we havn't fixed (yet).
Hopefully it will be resolved soon with the switch to a multi-language libtool.
From: bryce@albatross.co.nz
To: dey@nc.fnc.fujitsu.com, java-gnats@sourceware.cygnus.com,
tromey@cygnus.com
Cc:
Subject: Re: libgcj/67
Date: 7 Jun 2000 07:22:32 -0000
Old Synopsis: Core dump of simple application
New Synopsis: Solaris Linker Bug (Core dump of simple application)
State-Changed-From-To: feedback->open
State-Changed-By: bryce
State-Changed-When: Wed Jun 7 00:22:32 2000
State-Changed-Why:
This is presumed to be the solaris native-linker bug, which we havn't fixed (yet).
Hopefully it will be resolved soon with the switch to a multi-language libtool.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=67&database=java
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Thu Jun 22 16:49:46 2000
State-Changed-Why:
I'm closing this PR.
I believe this is the known problem that the Boehm GC
in libgcj 2.95.1 does not work on Solaris 2.7.
If you were using a newer libgcj, tell me, and I will
reopen the PR.
From: tromey@cygnus.com
To: dey@nc.fnc.fujitsu.com, java-gnats@sourceware.cygnus.com,
tromey@cygnus.com
Cc:
Subject: Re: libgcj/67
Date: 22 Jun 2000 23:49:46 -0000
Synopsis: Solaris Linker Bug (Core dump of simple application)
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Thu Jun 22 16:49:46 2000
State-Changed-Why:
I'm closing this PR.
I believe this is the known problem that the Boehm GC
in libgcj 2.95.1 does not work on Solaris 2.7.
If you were using a newer libgcj, tell me, and I will
reopen the PR.
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=67&database=java
>Unformatted:
More information about the Gcc-prs
mailing list