GCJ application runs not too bad with shared libs, but crasheswith static libs - seems to be in _Jv_MonitorEnter

[Scott Gilbertson]

> On Thu, 21 Nov 2002, Scott Gilbertson wrote:
> > I assume the problem is happening on the first call to the spin function
in
> > natObject, because that's the only time it calls is_mp.  I'm thinking
that
> > the reason the crash happens more easily when statically linked is due
to a
> > timing difference, but that the dynamic executable probably has the same
> > basic problem.
>
> I'm wondering if static memory isn't getting clobbered somehow by your
> program.  Clue #1 is that shared builds don't fail.  Clue #2 is the
> failure in is_mp, which ought have been initialized by then.  Clue #3 is
> the SIGSEGV in sscanf, as if a format string had been overwritten.
>
> Can you put a breakpoint on is_mp() and prove it is only called once?
>
> Jeff

I tried putting a breakpoint on is_mp, and it never broke.  Instead, I'd get
a break in sigsuspend.  Debugging a running program in gdb has been
problematic for me in general.

I commented out the sysconf call in is_mp (so is_mp always returns false),
and the thing seems pretty solid now (i.e., I've hammered at it for about
10-15 minutes without a crash).  I also made a little C program that prints
the results of the same sysconf call, to see if there's something screwy
with my setup, but the little program runs just fine.

BTW I get a warning compiling natObject.cc, but I doubt that has anything to
do with it.

In file included from ../../../gcc/libjava/java/lang/natObject.cc:281:
../../../gcc/boehm-gc/include/gc.h:53:1: warning: "GC_LINUX_THREADS"
redefined
../../../gcc/libjava/java/lang/natObject.cc:1:1: warning: this is the
location of the previous definition
(GC_LINUX_THREADS is defined in a "-D" on the command line from the
makefile)