Hi,
It now appears the bug is a problem in the JNI implementation -- see the
beginning of the stacktrace below:
(gdb) where
#0 0xfe29945c in __0fCosTget_native_priorityP6GThreadPiT () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#1 0xfe294b94 in __0fCosMget_priorityP6GThreadR6OThreadPriorityT ()
from /usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#2 0xfe2f9dc0 in __0fGThreadFprintv () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#3 0xfe19c588 in __0FMreport_errorlPCciNCCe () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#4 0xfe29a45c in
__0Fbhandle_unexpected_exceptionP6GThreadiP6HsiginfoPUcTE ()
from /usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#5 0xfe29d794 in JVM_handle_solaris_signal () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#6 0xff039348 in __libthread_segvhdlr () from
/usr/lib/libthread.so.1
#7 0xff03bdf0 in __sighndlr () from /usr/lib/libthread.so.1
#8 <signal handler called>
#9 0xfe1c93cc in __0FSregister_finalizerP6PinstanceOopDescP6GThread
() from /usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#10 0xfe1c9874 in __0fNinstanceKlassRallocate_instanceP6GThread () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#11 0xfe209b08 in jni_NewObject () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#12 0xfe7a3138 in Tclblend_Init () from
/usr/local/lib/tcljava1.3.0/libtclblend.so
#13 0xff310138 in Tcl_LoadObjCmd (dummy=0x0, interp=0x48848, objc=2,
objv=0x22efc8) at ./../generic/tclLoad.c:395
#14 0xff31ae98 in EvalObjv (interp=0x48848, objc=2, objv=0x22efc8,
command=0xff355e50 "", length=0, flags=262144)
at ./../generic/tclParse.c:932
As you can see, at stackframe 12 tclblend calls the JNI NewObject
function, and it's somewhere in the guts of the NewObject call
(stackframe 9) where the segmentation violation occurs. That's
the
same place it crashed in the stack trace Mo DeJong sent from JDK 1.1.8
from
Blackdown. I instrumented the code and I found that the
tcl.lang.Interp class is being instantiated the first time I do the
tcl
'package require java' command, but the second time I do the
'package
require java' command it doesn't make it to that class constructor.
Looks like it's dying somewhere in the JVM before the object gets
instantiated.
Note also that I determined it's not actually trying to load the
.so
file the second time (which you commented on in your previous
message). Rather, it sees that the Tclblend package is already
loaded
and then tries to call the package's initProc, and that initProc is
implemented in Tclblend_Init in tcljava/src/native/javaCmd.c, which
dies when it tries to do this:
local = (*env)->NewObject(env, java.Interp,
java.interpC, lvalue);
I sent mail to the Sun engineer who answered my bug submission
about
this, asking if he could provide me with source for JNI. I doubt
they
will, but it was worth asking.
One thing that is puzzling is how you got a crash in a different
place
when you tried it on IBM JDK 1.3. Seems odd that it would die
in
exactly the same place in JDK 1.1.8 from Blackdown and in Sun JS2E
v1.3
beta, but somewhere different on IBM JDK 1.3. Thoughts?
thanks,
- Mike
