Re: seg fault on startup

[Ben Tatham <bentatham at nanometrics dot ca>]

Well, I'm back...

Searching for the symbol to 0x7ffff998 has proven fruitless.  Talking 
with some of the guys here, we think it is extremely unlikely that it is 
a valid instruction address, being that it is so large.  Nothing seems 
to have a symbol for it. 

Being that I can get Foo to work as a statically linked version, I am 
going back to attempt to do our full application as static as well, but 
it seg faults much faster than Foo ever did.  Unfortunately, the stack 
trace gives no symbols, even on the debug version of it.  Not sure why.  
My guess is that it is not getting deep enough into anything to show 
symbols.  It seg faults immediately, so I think it is a different 
cause.  Statically linking gcj seems to be a non-trivial task in gcj 
4.1.2.  We are using the guidlines from here:

http://gcc.gnu.org/wiki/Statically_linking_libgcj?highlight=%28gcj%29. 

I am including the relevant portion of our makefile...we have a bunch of 
jars, that we make into .o files...As you can see, our app is called 
apollo. 

gccdir = /opt/gcc-4.1.2-glibc-2.3.3
platform=powerpc-860-linux-gnu

%.o : %.jar
       $(gccdir)/bin/$(platform)-gcj $(includes) -c -g -O $<

apollo : $(objects) ca.nanometrics.apollo.taurus.MissionControlTaurusmain.i
       $(gccdir)/bin/$(platform)-gcc -o apollo.debug $(objects) 
ca.nanometrics.apollo.taurus.MissionControlTaurusmain.i -shared-libgcc 
-Wl,-non-shared -lgcj -Wl,-call_shared -lsupc++ -Wl,--as-needed -lgcc_s 
-lpthread -lc -lm -ldl -Wl,--no-as-needed
       mv n-shared apollo.debug
       $(gccdir)/bin/$(platform)-strip --strip-debug apollo.debug -o apollo

ca.nanometrics.apollo.taurus.MissionControlTaurusmain.i : taurus.o
       $(gccdir)/bin/$(platform)-gcj 
--main=ca.nanometrics.apollo.taurus.MissionControlTaurus -save-temps -o 
temp.out $(objects)

Does anyway see any glaring mistakes in our logic?  We did remove -lz 
from th gcc command because we don't need it and gcc was complaining 
about it, but other than that, we think this is the same as the 
instructions on the wiki, except we are doing a lot more than just Foo.java.

-Ben



Andrew Haley wrote:
> Ben Tatham writes:
>  > Andrew Haley wrote:
>  > > Ben Tatham writes:
>  > >  > (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. 
>  > >
>  > > You need to go into the debugger to find out what is at
>  > >
>  > >   
>  > >>  > #5696 0x7ffff998 in ?? ()
>  > >>     
>  > 
>  > yes, but how? 
>
> Lots of ways.  Display the insns there with disp/i 0x7ffff998
> Put a BP on the caller.
>