Segmentation Fault

Fri Aug 6 05:27:00 GMT 1999

Do you mean linking the libgcj statically to my "Hello World"?
If this is the only way to get the gcj working correctly ...
Ciao,
Gregor
-----Original Message-----
From: Kresten Krab Thorup [ mailto:krab@gnu.org ]
Sent: Freitag, 6. August 1999 05:20
To: Frey, Gregor Karl Dr.
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: Segmentation Fault
"Frey, Gregor Karl Dr." <gregor.karl.frey@sap-ag.de> writes:
> _Jv_equalUtf8Consts (a=0x0, b=0xef6d204a)
> at ../../../libgcj-2.95/libjava/prims.cc:89
> #1 0xef6a6584 in _Jv_GetMethodLocal (klass=0xef71d284, name=0x0, 
> signature=0x0) at
../../../libgcj-2.95/libjava/java/lang/natClass.cc:527
> #2 0xef6a6340 in java::lang::Class::hackRunInitializers (this=0xef71d284)
> at ../../../libgcj-2.95/libjava/java/lang/natClass.cc:416
> #3 0xef6a3780 in java.lang.Class.hackTrampoline (this=0xef71d284, what=1,

> old_exception=0x0) at

What is happening here is, that the "module initializer" for the
module natClass.cc has not yet been run. (I.e., the logic that also
does C++ file-scope initialization). This renders the variable
`init_name' and `init_signature' unititialized (which asre the null
values you observe). This is strange, since you've reached main, and
this stuff happens in __main (which is secretly called as the first
thing in main). I had the same problem on Solaris a while back,
linking statically solved the problem, but that's a pain of cause.
(and not just a matter of saying -static on the command line.) I
didn't dive further into it, I just kept working on my i386-linux box
instead.
-- Kresten
 Kresten Krab Thorup, Ph.D. Candidate
 c/o Yonezawa Laboratory
 Department of Information Science 
 The University of Tokyo 
 7-3-1 Hongo, Bunkyo-ku, Tokyo 113 Japan
 Fax: +81-(0)3-5689-4365	 
 Phone: +81-(0)3-5841-4118
 Mobile: +81-(0)90-3693-5715