Re: gcj, gij; Classes cannot be found?

[Jeff Sturm <jsturm at one-point dot com>]

On Sun, 22 Jun 2003 weppnesp@eckerd.edu wrote:
> I see a couple problems, I am new to this (especially java in GDB) but
> what is the situation about this main file located in /tmp? Is that
> right?

Yes.  Since the libgcj runtime is built on a C runtime, it needs a C-style
main() function as an entry point.  The ordinary Java main() isn't enough.
So, it creates one for you when you compile with --main, and yes, it is
located in /tmp, and removed once it is compiled.  Run gcj with
-save-temps and you can see it.

(Good observation btw, clearly you're paying attention to what gdb is
telling you!)

> The backtrace looks good until it tries to go to the Class Package to find a
> Class name (the only one) and then the crash, why does it have problems?

It's trying to throw an exception and dying somewhere in the unwinder.
The fact that it is throwing isn't necessary a problem in itself;
exception handling is a normal part of libgcj startup as it tries to find
classes for charset conversion, etc.

So much for the easy questions... now the hard one:

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 20698)]
> 0x00006000 in ?? ()
> (gdb)
> (gdb) up
> #1  0x40394882 in _Jv_Throw (value=0x808cfa0) at exception.cc:100
> 100	  code = _Unwind_RaiseException (&xh->unwindHeader);

It looks as though it's failing to invoke _Unwind_RaiseException at all.
This function will be resolved in libgcc_s.so.  Make sure you're not
attaching to an incompatible libgcc_s.so on your system (if that's even
possible, and I question whether it is).  What does "ldd ./Hello" say?

This seems like some sort of bizzare failure of the runtime linker.  If
you are proficient at gdb, why not set a breakpoint on the previous
statement, step one instruction at a time and see exactly where it fails?

Jeff