On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
> I would love to give the answers to your good questions off the top of my head, but I
> don't know what "make test" does and I don't know what AutomaticSignature.test does.
>I
> am just following the installation and test instructions that came with the download.
> I can look into the makefile and the regression test files and try to figure it out.
>
> If it helps, here are the main and GC thread stack traces when it gets stuck:
>
> (gdb) thread 1
> [Switching to LWP 1 ]
> #0 0xef4b97c0 in _lwp_sema_wait ()
> (gdb) bt
> #0 0xef4b97c0 in _lwp_sema_wait ()
> #1 0xef447eb8 in _park ()
> #2 0xef447b9c in _swtch ()
> #3 0xef449314 in _mutex_adaptive_lock ()
> #4 0xef449020 in _cmutex_lock ()
> #5 0xef4567d4 in _pthread_mutex_lock ()
> #6 0xef398a6c in sysMonitorEnter ()
> #7 0xef385080 in monitorEnter ()
> #8 0xef37960c in jni_MonitorEnter ()
> #9 0xef37ee5c in invoke_MonitorEnter ()
> #10 0xef5673cc in JavaCmdProc ()
> #11 0xef6c6de4 in TclExecuteByteCode ()
> #12 0xef6a8438 in Tcl_EvalObjEx ()
> #13 0xef6f1d80 in Tcl_UplevelObjCmd ()
> #14 0xef6c6de4 in TclExecuteByteCode ()
> #15 0xef6a8438 in Tcl_EvalObjEx ()
> #16 0xef6f2440 in TclObjInterpProc ()
> #17 0xef6e9d90 in EvalObjv ()
> #18 0xef6ea4d0 in Tcl_EvalEx ()
> #19 0xef6dfe60 in Tcl_EvalFile ()
> #20 0xef6c6de4 in TclExecuteByteCode ()
> #21 0xef6a8438 in Tcl_EvalObjEx ()
> #22 0xef6acda8 in Tcl_CatchObjCmd ()
> #23 0xef6c6de4 in TclExecuteByteCode ()
> #24 0xef6a8438 in Tcl_EvalObjEx ()
> #25 0xef6aedc8 in Tcl_ForeachObjCmd ()
> #26 0xef6e9d90 in EvalObjv ()
> #27 0xef6ea4d0 in Tcl_EvalEx ()
> #28 0xef6dfe60 in Tcl_EvalFile ()
> #29 0xef6c6de4 in TclExecuteByteCode ()
> #30 0xef6a8438 in Tcl_EvalObjEx ()
> #31 0xef6d2980 in Tcl_RecordAndEvalObj ()
> #32 0xef6e3448 in Tcl_Main ()
> #33 0x116e4 in main ()
> (gdb) thread 4
> [Switching to LWP 4 ]
> #0 0xef4b97c0 in _lwp_sema_wait ()
> (gdb) bt
> #0 0xef4b97c0 in _lwp_sema_wait ()
> #1 0xef447eb8 in _park ()
> #2 0xef447b9c in _swtch ()
> #3 0xef4469a4 in _ti_cond_wait ()
> #4 0xef39acc8 in condvarWait ()
> #5 0xef398cc0 in sysMonitorWait ()
> #6 0xef366ad0 in finalizer_loop ()
> #7 0xef3993a4 in _start ()
>
> Mo DeJong wrote:
>
> > On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
> >
> > > I applied this patch and your other suggestion, and rebuilt, and now I cannot
> > > make it through the regression tests. tcljava/AutomaticSignature.test appears to
> > > deadlock. Can anyone help? My deadline is near, and I am close to having to
> > > abandon TclBlend as a solution, which I really do not want to have to do.
> >
> > Where is it getting stuck? Does it also get stuck in this same place
> > if you load Tcl Blend into a running Tcl shell instead of loading
> > both Tcl and Tcl Blend into a JVM? Is is a Tcl event loop problem
> > or a JVM problem?
> >
> > If finalization is the problem, why don't you try taking the finalization
> > methods out of the tcl.lang.Interp class? Try putting them into a
> > free() method that you can just call from your app when you
> > are done with the interp.
> >
> > Mo Dejong
> > Red Hat Inc.
Both threads seem to be going into sysMonitorEnter() and getting stuck
in there. What is odd about this is that the Interp is eval()ing code
so there is no way it should be getting garbage collected.
You are loading Tcl Blend into a JVM right? I was suggesting that
you try it the "normal" way (loading a JVM into Tcl) by running
the "make test" script to see if you get the same results. I
am a little confused as to how you would be running "make test"
if you are loading Tcl Blend into a JVM. The point of all this
is to see if the JVM is doing something strange even in the
"normal" case of loading a JVM into Tcl. (a JMV bug perhaps?)
You could also try removing the monitor enter code in java.h
and see if that does anything.
Change:
#define JAVA_LOCK() \
{ \
(*env)->MonitorEnter(env, java.NativeLock); \
oldEnv = JavaSetEnv(env); \
}
To:
#define JAVA_LOCK() \
{ \
/*(*env)->MonitorEnter(env, java.NativeLock);*/ \
oldEnv = JavaSetEnv(env); \
}
Do the same for JAVA_UNLOCK.
Mo Dejong
Red Hat Inc.
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
