On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
> 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.
It sounds like you are just running "regular" Tcl Blend, so it should
not be locking up like this. What version of Tcl are you using? You
should grab Tcl 8.3.1 if you are not using that already.
> 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.
Well, it is going into a monitor somewhere.
> > #6 0xef398a6c in sysMonitorEnter ()
> > #7 0xef385080 in monitorEnter ()
> > #8 0xef37960c in jni_MonitorEnter ()
> > #9 0xef37ee5c in invoke_MonitorEnter ()
> > #10 0xef5673cc in JavaCmdProc ()
I suggest that you compile Tcl with debug symbol and
then attach with gdb (or try the "make gdb" rule)
to find out what JavaCmdProc() is doing to enter
a monitor. That is what is locking up
your threads.
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
