seg fault on startup

Tue Mar 20 14:56:00 GMT 2007

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.
>