seg fault on startup

Mon Mar 19 18:29:00 GMT 2007

(gdb) info share
>From To Syms Read Shared Object Library
 No /usr/lib/libgcc_s.so.1
0x0f1e5000 0x0f9158a8 Yes /usr/lib/libgcj.so.7
0x0e7324f0 0x0e749f8c Yes /lib/libm.so.6
0x0e6c22b0 0x0e6ccc4c Yes /lib/libpthread.so.0
0x0e69bea0 0x0e69cd80 Yes /lib/libdl.so.2
0x0e551a40 0x0e6543e8 Yes /lib/libc.so.6
 No /lib/ld.so.1
And the links on my target platform...confirming I am running the 
correct shared libs. 
bash-2.05# ls -l /usr/lib/libgc*
lrwxrwxrwx 1 0 0 13 Jan 23 14:35 
/usr/lib/libgcc_s.so -> libgcc_s.so.1
lrwxrwxrwx 1 0 0 28 Mar 16 19:49 
/usr/lib/libgcc_s.so.1 -> /mnt/ide/usr/lib/libgcc_s.so
lrwxrwxrwx 1 511 511 17 May 1 2006 
/usr/lib/libgcc_s_nof.so -> libgcc_s_nof.so.1
-rwxr-xr-x 1 511 511 65999 Sep 27 2005 
/usr/lib/libgcc_s_nof.so.1
lrwxrwxrwx 1 0 0 15 Jan 23 14:35 
/usr/lib/libgcj.so.6 -> libgcj.so.6.0.0
-rwxr-xr-x 1 0 0 22862914 Jan 22 21:18 
/usr/lib/libgcj.so.6.0.0
lrwxrwxrwx 1 0 0 32 Mar 16 19:49 
/usr/lib/libgcj.so.7 -> /mnt/ide/usr/lib/libgcj.so.7.0.0
bash-2.05#
bash-2.05# ls -l /mnt/ide/usr/lib/libgc*
-rwxr-xr-x 1 0 0 76016 Mar 16 19:48 
/mnt/ide/usr/lib/libgcc_s.so
-rwxr-xr-x 1 0 0 76016 Mar 16 19:48 
/mnt/ide/usr/lib/libgcc_s.so.1
-rw-r--r-- 1 0 0 31823986 Mar 16 19:49 
/mnt/ide/usr/lib/libgcj.so.7
-rwxr-xr-x 1 0 0 49830629 Mar 19 16:54 
/mnt/ide/usr/lib/libgcj.so.7.0.0
-rwxr-xr-x 1 0 0 31823986 Mar 16 19:49 
/mnt/ide/usr/lib/libgcj.so.7.0.0.stripped
bash-2.05#
However, I was making a mistake earlier...I had foo.debug and Foo.debug, 
but my silly windows intermediary screwed up the ftps to my target, so I 
wasn't actually running the debug version of the statically linked 
version. Anyway, the point is that the statically linked version of Foo 
works in both the stripped and non-stripped cases -- which would seem to 
indicate that perhaps it is not the correct version of libgcj...but as 
far as I can tell, I do have the correct versions. 
Other versions of interest, libc.so: 2.3.1. Our GCJ is technically 
compiled for libc 2.3.3, but we have been running gcc-4.0.1-libc-2.3.3 
for some time without a problem. We cannot seem to compile gcc/gcj 
4.1.2-libc-2.3.1 though. And besides, the statically linked version 
still depends on libc, ld, lm, etc. and works fine, so I don't think 
that is the problem. 
Ben.
Andrew Haley wrote:
> Ben Tatham writes:
> > Actually, the bottom of the stack has a bit more...sorry.
> > 
> > 
> > #5693 0x0f1e686c in catch_segv (_sc=@7fc00570) at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/prims.cc:151
> > #5694 0x7ffff3d8 in ?? ()
> > #5695 0x0f1e686c in catch_segv (_sc=@7fc00570) at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/prims.cc:151
> > 
> > #5696 0x7ffff998 in ?? ()
> > 
> > #5697 0x0f21db74 in java::lang::Class::initializeClass (this=@fd40240)
> > at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/java/lang/natClass.cc:737
> > #5698 0x0f1e783c in _Jv_CreateJavaVM (vm_args=null) at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/java/lang/Class.h:599
> > #5699 0x0f1e7c68 in _Jv_RunMain (vm_args=null, klass=@100121e0, 
> > name=null, argc=1, argv=@7ffffdd4, is_jar=false)
> > at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/prims.cc:1355
> > 
> > #5700 0x0f1e7dbc in _Jv_RunMain (klass=@14, name=@f1e686c, 
> > argc=264674640, argv=@fc69d30, is_jar=false)
> > at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/prims.cc:1401
> > 
> > #5701 0x0f1e7dec in JvRunMain (klass=@300763f0, argc=805790704, argv=@8) 
> > at 
> > /disk1/xtool/crosstool-0.43/build/powerpc-860-linux-gnu/gcc-4.1.2-glibc-2.3.3/gcc-4.1.2/libjava/prims.cc:1407
> > #5702 0x10001ae4 in main ()
> > Current language: auto; currently java
> > (gdb)
>> Eww, that's just as nasty. We still don't know what's at 0x7ffff998.
> If you can run gdb, even stripped, `info share' should help.
>> Taking a step back for a moment, you need somehow to figure out what
> is running, and why. Are you absolutely sure that you have installed
> the correct libgcj, for example?
>> Andrew.
>