Re: seg fault on startup

[Ben Tatham <bentatham at nanometrics dot ca>]

wow.  fast response.  does "debuginfo" refer to something i'm not 
familiar with, or is that just generic debug info?    what sort of other 
info do you need...i tried to give as much of the enviroment that I 
thought necessary.

Yes, I have tried it with libgcj stripped, and well as unstripped.  I 
have tried things with both libc 2.3.3 and libc 2.3.6.  (We prefer to 
stay at libc 2.3.3 so we don't have to change others of our linux bins, 
but it doesn't work either anyway...)

Here's some more debuginfo...the readelf -d of the working and not work 
Foo execs...not sure if the problem is related to any of this or not...

WORKING VERSION:

Dynamic segment at offset 0x49bf8c contains 24 entries:
 Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
0x00000001 (NEEDED)                     Shared library: [ld.so.1]
0x0000000c (INIT)                       0x10002f80
0x0000000d (FINI)                       0x10324ab4
0x00000004 (HASH)                       0x10000164
0x00000005 (STRTAB)                     0x10001768
0x00000006 (SYMTAB)                     0x10000848
0x0000000a (STRSZ)                      2674 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x105fb1cc
0x00000002 (PLTRELSZ)                   2544 (bytes)
0x00000014 (PLTREL)                     RELA
0x00000017 (JMPREL)                     0x10002590
0x00000007 (RELA)                       0x10002530
0x00000008 (RELASZ)                     2640 (bytes)
0x00000009 (RELAENT)                    12 (bytes)
0x6ffffffe (VERNEED)                    0x100023c0
0x6fffffff (VERNEEDNUM)                 5
0x6ffffff0 (VERSYM)                     0x100021da
0x00000000 (NULL)                       0x0


NOT WORKING VERSION:

Dynamic segment at offset 0x206c contains 25 entries:
 Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED)                     Shared library: [libgcj.so.7]
0x00000001 (NEEDED)                     Shared library: [libm.so.6]
0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000c (INIT)                       0x100018f0
0x0000000d (FINI)                       0x10001f40
0x00000004 (HASH)                       0x10000164
0x00000005 (STRTAB)                     0x10000e90
0x00000006 (SYMTAB)                     0x100005b0
0x0000000a (STRSZ)                      2074 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x100122a0
0x00000002 (PLTRELSZ)                   144 (bytes)
0x00000014 (PLTREL)                     RELA
0x00000017 (JMPREL)                     0x10001860
0x00000007 (RELA)                       0x100017e8
0x00000008 (RELASZ)                     264 (bytes)
0x00000009 (RELAENT)                    12 (bytes)
0x6ffffffe (VERNEED)                    0x100017c8
0x6fffffff (VERNEEDNUM)                 1
0x6ffffff0 (VERSYM)                     0x100016aa
0x00000000 (NULL)                       0x0











Andrew Haley wrote:
> Ben Tatham writes:
>
>  > I am building an application for Linux 2.4 with GCJ 4.1.2 for libc
>  > 2.3.3 for powerpc-860.  Unfortunately, the application crashes on
>  > startup everytime.  I have gone back to trying to build a simple
>  > Hello World app, and the only version I can get to run is on that
>  > is stripped and statically linked.  If I don't strip it or if I try
>  > and use the shared libgcj, it seg faults.  Even if the libgcj is
>  > also stripped.
>  > 
>  > Otherwise, no matter what I seem to do to either my Foo app or my
>  > real application, I always get a Segmentation Fault.
>  > 
>  > The backtrace as seen from the core dump is:
>  > (gdb) bt
>  > #0  0x0f44019c in java::lang::NullPointerException::NullPointerException() ()
>  >     from /usr/lib/libgcj.so.7
>  > #1  0x0f1e6874 in catch_segv(int, sigcontext*) () from /usr/lib/libgcj.so.7
>  > #2  0x7fc00748 in ?? ()
>  > (gdb)
>  > 
>  > If I run the app from within gdb, I can the following backtrace:
>  > 
>  > #0  0x0f43f5e4 in java::lang::VMThrowable::__U3c_clinit__U3e_() ()
>  >     from /usr/lib/libgcj.so.7
>  > #1  0x0f21db88 in java::lang::Class::initializeClass() ()
>  >     from /usr/lib/libgcj.so.7
>  > #2  0x0f1e783c in _Jv_CreateJavaVM(_Jv_VMInitArgs*) ()
>  >     from /usr/lib/libgcj.so.7
>  > #3  0x0f1e7c68 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char const*, int, char const**, 
>  > bool) () from /usr/lib/libgcj.so.7
>  > #4  0x0f1e7dbc in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) () from 
>  > /usr/lib/libgcj.so.7
>  > #5  0x0f1e7dec in JvRunMain () from /usr/lib/libgcj.so.7
>  > 
>  > 
>  > We are upgrading from 4.0.1, and we had upgraded GCJ many times
>  > before, with problems always being on the compile side of things
>  > and were always resolved.  This time, its the runtime side...what
>  > the difference this time, I have no idea.
>  > 
>  > Has anyone seen anything like this before?  Any help is appreciated...
>
> This is weird.  Is your dynamic libgcj stripped too?  We really need
> debuginfo here, or we'll never get started at all.
>
> Andrew.
>