libgcj/1445: Uninitialized global variables
patha@ida.liu.se
patha@ida.liu.se
Wed Dec 20 12:29:00 GMT 2000
>Number: 1445
>Category: libgcj
>Synopsis: Uninitialized global variables
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tromey
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:19:56 PST 2000
>Closed-Date: Fri Oct 08 08:58:05 PDT 1999
>Last-Modified: Fri Oct 08 08:58:05 PDT 1999
>Originator: Patrik Hägglund
>Release: 2.95.1
>Organization:
>Environment:
sparc-sun-solaris2.7
gcc-2.95.1 compiled with --enable-threads
boehm-gc replaced with gc5.0a3
(gc4.13a2 doesn't work on solaris2.7)
>Description:
I found three uninitialized global variabels in natClass.cc
around line 60:
// Some constants we use to look up the class initializer.
static _Jv_Utf8Const *void_signature = _Jv_makeUtf8Const ("()V", 3);
static _Jv_Utf8Const *clinit_name = _Jv_makeUtf8Const ("<clinit>", 8);
static _Jv_Utf8Const *init_name = _Jv_makeUtf8Const ("<init>", 6);
(gdb) bt
#0 _Jv_equalUtf8Consts (a=0x0, b=0x7fad558a) at ../../../libjava/prims.cc:89
#1 0x7faa73bc in _Jv_GetMethodLocal (klass=0x2e120, name=0x0, signature=0x0)
at ../../../libjava/java/lang/natClass.cc:534
#2 0x7faa7370 in java::lang::Class::hackRunInitializers (this=0x2e120)
at ../../../libjava/java/lang/natClass.cc:423
#3 0x7faa3f68 in java.lang.Class.hackTrampoline (this=0x2e120, what=1,
old_exception=0x0) at ../../../libjava/java/lang/Class.java:137
#4 0x7faa6854 in java::lang::Class::initializeClass (this=0x2e120)
at ../../../libjava/java/lang/natClass.cc:496
#5 0x7faa3f40 in java.lang.Class.hackTrampoline (this=0x2e120, what=0,
old_exception=0x0) at ../../../libjava/java/lang/Class.java:135
#6 0x7faa6810 in java::lang::Class::initializeClass (this=0x7fb14710)
at ../../../libjava/java/lang/natClass.cc:482
#7 0x7faa7424 in _Jv_InitClass (klass=0x7fb14710)
at ../../../libjava/java/lang/natClass.cc:572
#8 0x7fa3040c in _Jv_AllocObject (c=0x7fb14710, size=32)
at ../../../libjava/prims.cc:266
#9 0x7faa9f20 in _Jv_AllocString (len=6) at ../../../libjava/include/cni.h:31
#10 0x7faa975c in _Jv_NewStringUtf8Const (str=0x0)
at ../../../libjava/java/lang/natString.cc:226
#11 0x7faa665c in java::lang::Class::resolveConstants (this=0x7fb14710)
at ../../../libjava/java/lang/natClass.cc:399
#12 0x7faa6730 in java::lang::Class::initializeClass (this=0x7fb14710)
at ../../../libjava/java/lang/natClass.cc:447
#13 0x7faa7424 in _Jv_InitClass (klass=0x7fb14710)
at ../../../libjava/java/lang/natClass.cc:572
#14 0x7fa3040c in _Jv_AllocObject (c=0x7fb14710, size=24)
at ../../../libjava/prims.cc:266
#15 0x7faa9f20 in _Jv_AllocString (len=2) at ../../../libjava/include/cni.h:31
#16 0x7faa975c in _Jv_NewStringUtf8Const (str=0x0)
at ../../../libjava/java/lang/natString.cc:226
#17 0x7faa665c in java::lang::Class::resolveConstants (this=0x7fb1560c)
at ../../../libjava/java/lang/natClass.cc:399
#18 0x7faa6730 in java::lang::Class::initializeClass (this=0x7fb1560c)
at ../../../libjava/java/lang/natClass.cc:447
#19 0x7faa3f40 in java.lang.Class.hackTrampoline (this=0x7fb1560c, what=0,
old_exception=0x0) at ../../../libjava/java/lang/Class.java:135
#20 0x7faa6810 in java::lang::Class::initializeClass (this=0x2e440)
at ../../../libjava/java/lang/natClass.cc:482
#21 0x7faa3f40 in java.lang.Class.hackTrampoline (this=0x2e440, what=0,
old_exception=0x0) at ../../../libjava/java/lang/Class.java:135
#22 0x7faa6810 in java::lang::Class::initializeClass (this=0x2e490)
at ../../../libjava/java/lang/natClass.cc:482
#23 0x7faa3f40 in java.lang.Class.hackTrampoline (this=0x2e490, what=0,
old_exception=0x0) at ../../../libjava/java/lang/Class.java:135
#24 0x7faa6810 in java::lang::Class::initializeClass (this=0x7fb13654)
at ../../../libjava/java/lang/natClass.cc:482
#25 0x7faa7424 in _Jv_InitClass (klass=0x7fb13654)
at ../../../libjava/java/lang/natClass.cc:572
#26 0x7fa2fad8 in JvRunMain (klass=0x2c2f4, argc=1, argv=0xffbedfa4)
at ../../../libjava/prims.cc:266
#27 0x16448 in main (argc=1, argv=0xffbedfa4)
I tried to use functions with static local variables as described
by Stroustrup, p 217, but I didn't liked the solution. It is
probably better to initialize globals explicitly somewhere. You
probably know where to do this better than I.
Before, I mangaged to avoid this bug by using
CXXFLAGS/CFLAGS=-O3. This doesn't work with --enable-threads,
though.
Using the trick with functions described above, one more bug of
the same kind was revealed. However, I can't easily spot the
offending variable in this case.
(gdb) bt
#0 _Jv_FindArrayClass (element=0x2e3f0)
at ../../../libjava/java/lang/natClass.cc:717
#1 0x7fa2f9a0 in _Jv_FindClassFromSignature (sig=0x1b131 "[I", loader=0x0)
at ../../../libjava/prims.cc:535
#2 0x7fa2f998 in _Jv_FindClassFromSignature (sig=0x1b130 "[[I", loader=0x0)
at ../../../libjava/prims.cc:535
#3 0x7faa6824 in java::lang::Class::resolveConstants (this=0x2c0a4)
at ../../../libjava/java/lang/natClass.cc:406
#4 0x7faa69a4 in java::lang::Class::initializeClass (this=0x2c0a4)
at ../../../libjava/java/lang/natClass.cc:447
#5 0x7faa75a4 in _Jv_InitClass (klass=0x2c0a4)
at ../../../libjava/java/lang/natClass.cc:572
#6 0x7fa3040c in _Jv_AllocObject (c=0x2c0a4, size=40)
at ../../../libjava/prims.cc:266
#7 0x15cf0 in Test::main ()
#8 0x7faa8298 in java::lang::FirstThread::run (this=0x7f7cbf00)
at ../../../libjava/java/lang/natFirstThread.cc:55
#9 0x7fa64b08 in java.lang.Thread.run_ (this=0x7f7cbf00)
at ../../../libjava/java/lang/Thread.java:119
#10 0x7faac138 in java::lang::Thread::run__ (obj=0x7f7cbf00)
at ../../../libjava/java/lang/natThread.cc:257
#11 0x7fabc840 in _Jv_ThreadStart (thread=0x7f7cbf00,
meth=0x7faac12c <java::lang::Thread::run__(java::lang::Object *)>)
at ../../../libjava/no-threads.cc:25
#12 0x7faac1b0 in java::lang::Thread::start (this=0x7f7cbf00)
at ../../../libjava/java/lang/natThread.cc:270
#13 0x7fa2fe94 in JvRunMain (klass=0x2c2f4, argc=2138890236, argv=0xffbedfa8)
at ../../../libjava/prims.cc:589
#14 0x16448 in main (argc=1, argv=0xffbedfa4)
(gdb) p element->name
$5 = (_Jv_Utf8Const *) 0x0
>How-To-Repeat:
Try to compile and run this program:
public class Hello {
public static void main(String[] args) {
System.out.println("Hej");
}
}
>Fix:
>Release-Note:
>Audit-Trail:
Formerly PR libgcj/65
From: Tom Tromey <tromey@cygnus.com>
To: patha@ida.liu.se
Cc: java-gnats@sourceware.cygnus.com, Warren Levy <warrenl@cygnus.com>
Subject: Re: libgcj/65: Uninitialized global variables
Date: Thu, 7 Oct 1999 12:45:13 -0700
This is the famous Solaris bug.
gcj and the Solaris ld don't work well together.
Instead you must use the GNU binutils linker.
I'll close this PR in a bit, since it is already known.
Warren, is this in the FAQ? If not, I guess I could submit a PR
against the FAQ.
T
From: Warren Levy <warrenl@cygnus.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: patha@ida.liu.se, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/65: Uninitialized global variables
Date: Thu, 7 Oct 1999 14:10:58 -0700 (PDT)
On Thu, 7 Oct 1999, Tom Tromey wrote:
> This is the famous Solaris bug.
> gcj and the Solaris ld don't work well together.
> Instead you must use the GNU binutils linker.
>
> I'll close this PR in a bit, since it is already known.
>
> Warren, is this in the FAQ? If not, I guess I could submit a PR
> against the FAQ.
Ooh, my bad. I have this in my local tree and need to fold it into the
FAQ with other Q&A's I came up with. I was going to do this a week ago
but switched gears when some other priority Java work came up. I'll fold
this in either tonight or tomorrow morning. Don't bother filing a PR.
--warrenl
From: Tom Tromey <tromey@cygnus.com>
To: Patrik Hagglund <patha@ida.liu.se>
Cc: Tom Tromey <tromey@cygnus.com>,
Java Gnats Server <java-gnats@sourceware.cygnus.com>
Subject: Re: libgcj/65: Uninitialized global variables
Date: Thu, 7 Oct 1999 15:13:55 -0700
Please continue to CC java-gnats, so that this information is logged.
>>>>> "Patrik" == Patrik Hagglund <patha@ida.liu.se> writes:
>> This is the famous Solaris bug.
Patrik> Wait a minute. Do you mean that semantics of the code is
Patrik> well-defined?
I believe so. Those variables should be initialized before main() is
run -- at the same time C++ static constructors are run (since this is
what they are).
They are not run correctly due to a linker bug, or a gcc/linker
interaction problem (I don't know the details). Using GNU binutils
fixes this.
Patrik> binutils 2.9.1 has known bugs on this platform. We recommend
Patrik> to use the vendor tools (Sun as, Sun ld) until these have been
Patrik> fixed.
I don't know what version other people are using, but we have heard
reports that using the binutils "ld" fixes the problem. Perhaps
people are using a binutils snapshot.
Tom
From: Tom Tromey <tromey@cygnus.com>
To: Patrik Hagglund <patha@ida.liu.se>
Cc: Tom Tromey <tromey@cygnus.com>,
Java Gnats Server <java-gnats@sourceware.cygnus.com>
Subject: Re: libgcj/65: Uninitialized global variables
Date: Thu, 7 Oct 1999 15:32:11 -0700
>>>>> "Patrik" == Patrik Hagglund <patha@ida.liu.se> writes:
Patrik> /home/pelab/pub/pkg/binutils-991002/bin/ld: bfd assertion fail ../../bfd/elflink.h:1566
I have never seen this.
Patrik> And when I replaced ld with Sun's ld:
Patrik> ld: warning: file /home/pelab/pub/pkg/libgcj-2.95.1_gc5.0a3_gcc-2.95.1-threads_binutils-991002/lib/libgcj.so: section .stabstr: malformed string table, initial or final byte
... or this.
Patrik> The program gives this waring message:
Patrick> ./Hello
Patrik> Large stack limit(2147479552): only scanning 8 MBHello
... or this.
I don't remember anybody else trying Solaris 2.7, either, so you're in
untested waters.
Tom
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Fri Oct 8 08:58:05 1999
State-Changed-Why:
I'm closing this, since the reported bug is the
Solaris problem which we know how to fix.
Patrik, feel free to submit a new Solaris 2.7-related PR
if you want. I don't know when I'll be able
to look at it though :-(
>Unformatted:
More information about the Gcc-prs
mailing list