[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
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. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
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 LWP1]
#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 LWP4]
#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]
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
I am not sure about how well JDK 1.1.8 work with TclBlend. I have not tested TclBlend with JDK 1.1.8. Are you unable to upgrade to JDK 1.2? -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 13, 2000 11:31 AM To: Jiang Wu Subject: Re: trouble in patchland I am using the native-thread JDK 1.1.8 on Solaris. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
I repeated the test of the patch, with JDK 1.2 on Solaris. Same result... hanging in AutomaticSignature.test. Jiang Wu wrote: I am not sure about how well JDK 1.1.8 work with TclBlend. I have not tested TclBlend with JDK 1.1.8. Are you unable to upgrade to JDK 1.2? -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 13, 2000 11:31 AM To: Jiang Wu Subject: Re: trouble in patchland I am using the native-thread JDK 1.1.8 on Solaris. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
When I started this project back in March, I could not get anything to work with JDK 1.1.8, Tcl 8.3, and TclBlend 1.2.5, so I used Tcl 8.2.3. I do not remember now what the symptom was, just that it didn't work. (I am using JDK 1.1.8 because of warnings about JDK 1.2 at http://dev.scriptics.com/software/java/faq.html#Q4.) Thats is odd, the only problem I know of is Tcl 8.2 and the whole vfork vs fork mess. Tcl 8.3 is the way to go if you ask me. That "warning" about JDK 1.2 only matters if you are using the TclClassloader to load new .class files without putting them on the CLASSPATH. Tcl, or TclBlend? I have not compiled Tcl... should I? (I'm using the binary distribution of Tcl.) I will see if I can get anywhere with this approach. Ok, the very first thing you need to do is nuke and precompiled code and compile Tcl 8.3.1 with debug symbols enabled. Then reconfigure and rebuild Tcl Blend, it will automatically notice that you compiled Tcl with debug and include debug info in libtclblend.so. This sort of thing is the exact reason there are only Windows binaries on the Tcl Blend 1.2.6 download site. It is safer to just build things by yourself. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
Sigh. I can do that for my testing, certainly. But you may recall that my constraint in production is that I am not the one that is invoking Tcl--Vignette's StoryServer product is invoking Tcl. And they are using Tcl 8.2.0. Not even 8.2.3. (At least that's what [info patchlevel] says.) Mo DeJong wrote: When I started this project back in March, I could not get anything to work with JDK 1.1.8, Tcl 8.3, and TclBlend 1.2.5, so I used Tcl 8.2.3. I do not remember now what the symptom was, just that it didn't work. (I am using JDK 1.1.8 because of warnings about JDK 1.2 at http://dev.scriptics.com/software/java/faq.html#Q4.) Thats is odd, the only problem I know of is Tcl 8.2 and the whole vfork vs fork mess. Tcl 8.3 is the way to go if you ask me. That "warning" about JDK 1.2 only matters if you are using the TclClassloader to load new .class files without putting them on the CLASSPATH. Tcl, or TclBlend? I have not compiled Tcl... should I? (I'm using the binary distribution of Tcl.) I will see if I can get anywhere with this approach. Ok, the very first thing you need to do is nuke and precompiled code and compile Tcl 8.3.1 with debug symbols enabled. Then reconfigure and rebuild Tcl Blend, it will automatically notice that you compiled Tcl with debug and include debug info in libtclblend.so. This sort of thing is the exact reason there are only Windows binaries on the Tcl Blend 1.2.6 download site. It is safer to just build things by yourself. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
Sorry, it was unintentional. This was my transmission:
Well, JavaCmdProc() is just calling EnterMonitor. Here's the code:
/*
* Invoke the command by calling Interp.callCommand(). Be sure to
* leave the monitor since we are assuming nothing about the state
* of the world after this call.
*/
(*env)-MonitorExit(env, java.NativeLock);
result = (*env)-CallIntMethod(env, interpObj,
java.callCommand, cmd, args);
exception = (*env)-ExceptionOccurred(env);
(*env)-MonitorEnter(env, java.NativeLock);
if (exception) {
(*env)-ExceptionClear(env);
}
Mo DeJong wrote:
Please do not post to the tclava list in HTML! That is just about
as bad as spamming people.
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
