[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
[Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
Dr Wes Munsil wrote: MAIN THREAD #4 0xee99acc8 in condvarWait () #5 0xee998cc0 in sysMonitorWait () #6 0xee96638c in runFinalization0 () #7 0xee968d44 in manageAllocFailure () #8 0xee96749c in realObjAlloc () Looks here like the heap is exhausted, so the VM tries to run finalizers immediately. That's a little unusual for async GC. Either there aren't enough idle cycles for GC to run, or the initial heap is too small. GARBAGE COLLECTION THREAD #5 0xef2d67d4 in _pthread_mutex_lock () #6 0xee998a6c in sysMonitorEnter () #7 0xee985080 in monitorEnter () #8 0xee97960c in jni_MonitorEnter () #9 0xeea4679c in Java_tcl_lang_CObject_decrRefCount () #10 0xee99c504 in desc_loop () #11 0xee95f7b0 in invokeJNINativeMethod () #12 0xee99cdd8 in notJavaInvocation () #13 0xee9711ec in do_execute_java_method_vararg () #14 0xee970b9c in do_execute_java_method () #15 0xee966b68 in finalizer_loop () Here it looks like the GC thread is trying to run finalizers too. I worry a bit about the monitors... what finalizers are running, and what do they do? Any use of synchronization inside finalizers is usually a bad idea, and did cause deadlocks in 1.1.x (I heard Sun fixed this in 1.2.x though). Finalizers are best avoided if at all possible. They have caused more problems than perhaps any other feature of Java. Jeff 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] finalization deadlock under Solaris
Re heap exhaustion: either or both may be true, although the code is incorrect if it deadlocks under those conditions. While increasing the initial heap allocation may certainly be desirable, I am afraid that it would not fix the incorrect code, but only make its effects felt less often. Re finalize methods: our code contains none. There are of course some in the JDK (1.1.8), but other than that the only ones of which I am aware are one in the Xerces XML parser, which we use, and two in TclBlend itself (in Interp and CObject). I had hoped that by now someone would have discovered a problem with the TclBlend finalizers. Perhaps this example has uncovered one. Jeff Sturm wrote: Dr Wes Munsil wrote: MAIN THREAD #4 0xee99acc8 in condvarWait () #5 0xee998cc0 in sysMonitorWait () #6 0xee96638c in runFinalization0 () #7 0xee968d44 in manageAllocFailure () #8 0xee96749c in realObjAlloc () Looks here like the heap is exhausted, so the VM tries to run finalizers immediately. That's a little unusual for async GC. Either there aren't enough idle cycles for GC to run, or the initial heap is too small. GARBAGE COLLECTION THREAD #5 0xef2d67d4 in _pthread_mutex_lock () #6 0xee998a6c in sysMonitorEnter () #7 0xee985080 in monitorEnter () #8 0xee97960c in jni_MonitorEnter () #9 0xeea4679c in Java_tcl_lang_CObject_decrRefCount () #10 0xee99c504 in desc_loop () #11 0xee95f7b0 in invokeJNINativeMethod () #12 0xee99cdd8 in notJavaInvocation () #13 0xee9711ec in do_execute_java_method_vararg () #14 0xee970b9c in do_execute_java_method () #15 0xee966b68 in finalizer_loop () Here it looks like the GC thread is trying to run finalizers too. I worry a bit about the monitors... what finalizers are running, and what do they do? Any use of synchronization inside finalizers is usually a bad idea, and did cause deadlocks in 1.1.x (I heard Sun fixed this in 1.2.x though). Finalizers are best avoided if at all possible. They have caused more problems than perhaps any other feature of Java. Jeff 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