Thank you for your response. I am running "make test". (I don't know who loads whom,
but I
infer from your comments that that means I am loading a JVM into Tcl.) I had removed
the
MonitorEnter calls from JAVA_LOCK and JAVA_UNLOCK in response to an earlier suggestion
from
Jiang Wu.
The history is this: I applied Jiang Wu's source patch to TclBlend 1.2.5 and removed
the
MonitorEnter calls. Then I ran "make test" just to see if things were still working.
They
were not.
I agree that there seems to be no indication from these stack traces that garbage
collection
is in process.
Mo DeJong wrote:
> 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
