GCJ application runs not too bad with shared libs, but crasheswith static libs - seems to be in _Jv_MonitorEnter
Fri Nov 22 09:32:00 GMT 2002
> On Thu, 21 Nov 2002, Scott Gilbertson wrote:
> > I assume the problem is happening on the first call to the spin function
> > natObject, because that's the only time it calls is_mp. I'm thinking
> > the reason the crash happens more easily when statically linked is due
> > 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?
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"
../../../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
More information about the Java