[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
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.
Jiang Wu wrote:
> Yes. You can download the patch from:
>
> http://www-cs-students.stanford.edu/~jwu/tclblend.patch
>
> Note that the patch does NOT remove the JAVA_LOCK code in TclBlend. It is
> still possible to deadlock after applying the patch due to JAVA_LOCK. Your
> stack trace looks JAVA_LOCK is causing the problem. When I did the patch, I
> did not realize the possibility of a garbage collector thread accessing
> TclBlend.
>
> The patch allows one to use TclBlend from "one and only one thread" without
> any problems. In your case, both the garbage collector thread and the main
> thread are using TclBlend! This can cause deadlock.
>
> You probably want to apply the patch and remove the JAVA_LOCK. To remove
> JAVA_LOCK, you should change the #define JAVA_LOCK and #define JAVA_UNLOCK
> in java.h of TclBlend to remove the lines that do MonitorEnter and
> MonitorExit:
>
> #define JAVA_LOCK() \
> { \
> /* (*env)->MonitorEnter(env, java.NativeLock); \ <--- comment out this
> line */
> oldEnv = JavaSetEnv(env); \
> }
>
> #define JAVA_UNLOCK() \
> { \
> JavaSetEnv(oldEnv); \
> /* (*env)->MonitorExit(env, java.NativeLock); \ <--- comment out this
> line */
> }
>
> You need to leave the other lines that sets the java environment unchanged
> because TclBlend depends on that.
>
> -- Jiang Wu
>[EMAIL PROTECTED]
>
> -Original Message-
> From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 04, 2000 9:46 PM
> To: Scott Redman
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
>
> Thank you. Would that be "The Mythical TclBlend Patch" of April 4? It's
> certainly
> worth a try. Does anyone have TclBlend 1.2.5 with this patch applied built
> for
> Solaris?
>
> Scott Redman wrote:
>
> > Try commenting out the JAVA_LOCK() code in the the TclBlend
> > .c files (actually, just change the #define in the header).
> > Or, try using Jiang Wu's patch (see the archive for this
> > mailing list). Jiang's patch is safer.
> >
> > -- Scott
> >
> > Dr Wes Munsil wrote:
> > >
> > > [Sorry if this is duplicated. May have sent to the wrong place first. Or
> > > not.]
> > >
> > > I seem to be encountering a deadlock in finalization in TclBlend. I am
> > > running JDK 1.1.8, Tcl 8.2.3, and TclBlend 1.2.5 under Vignette's
> > > StoryServer 5.0 page-generation product on SunOS 5.6. When the
> > > page-generation process hangs, I take a stack snapshot, and what I think
> > > are the main thread and the garbage collection thread stacks look
> > > suspicious. They are listed below. Do you have any ideas as to what's
> > > going on, and what I can do about it? I'd try setting tclblend_init to
> > > "-noasyncgc", but that apparently only works with JDK 1.2.2, and in any
> > > case I'm afraid that would just make the problem happen less often
> > > instead of solving it.
> > >
> > > Thank you.
> > >
> > > MAIN THREAD
> > >
> > > #0 0xeeb397c0 in _lwp_sema_wait ()
> > > #1 0xef2c7eb8 in _park ()
> > > #2 0xef2c7b9c in _swtch ()
> > > #3 0xef2c68bc in _cond_wait_cancel ()
> > > #4 0xee99acc8 in condvarWait ()
> > > #5 0xee998cc0 in sysMonitorWait ()
> > > #6 0xee96638c in runFinalization0 ()
> > > #7 0xee968d44 in manageAllocFailure ()
> > > #8 0xee96749c in realObjAlloc ()
> > > #9 0xee966eb0 in cacheAlloc ()
> > > #10 0xee967210 in realObjAlloc ()
> > > #11 0xee967ad0 in ObjAlloc ()
> > > #12 0xee9600c0 in newobject ()
> > > #13 0xee9a0de0 in new_quick_0 ()
> > > #14 0xee974708 in jni_Invoke ()
> > > #15 0xee976394 in jni_CallVoidMethodV ()
> > > #16 0xee97ab5c in invoke_CallVoidMethod ()
> > > #17 0xeea46324 in FreeTclObject ()
> > > #18 0xef05c7f4 in TclFreeObj ()
> > > #19 0xef05ed50 in Tcl_EvalEx ()
> > > #20 0xef05e9f4 in Tcl_EvalTokens ()
> > > #21 0xef05eccc in Tcl_EvalEx ()
> > > #22 0xef05e9f4 in Tcl_EvalTokens ()
> > > #23 0xef05eccc in Tcl_EvalEx ()
> > > #24 0xef05ef04 in Tcl_Eval ()
> > > #25 0xef715e70 in __0fJctlInterpHevalTclRPCcPCcR6JctlBufferi ()
> > > #26 0xef715a24 in __0fJctlInterpMevalTemplatePCcUiR6JctlBufferi ()
> > > #27 0xef716f7c in __0fJctlInterpEEVALPvP6KTcl_InterpiPPcT ()
> > > #28 0x2f8d8 in __0FCIFPvP6KTcl_InterpiPPc ()
> > > #29 0xef021e7c in TclInvokeStringCommand ()
> > > #30 0xef05e69c in EvalObjv ()
> > > #31 0xef05ed18 in Tcl_EvalEx ()
> > > #32 0xef05ef04 in Tcl_Eval ()
> > > etc...
> > >
> > > GARBAGE COLLECTION THREAD
> > >
> > > #0 0xeeb397c0 in _lwp_sema_wait ()
> > > #1 0xef2c7eb8 in _park ()
> > > #2 0xef2c7b9c in _swtch ()
> > > #3 0xef2c9314 in _mutex_adaptive_lock ()
> > > #4 0xef2c9020 in _cmutex_lock ()
> > > #5 0xef2d67d4 in _pthread_mutex_lock ()
> > > #6 0xee99
[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
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. 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
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]
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] ANNOUNCE: SWANK 0.5
This is to announce the release of version 0.5 of SWANK(tm), a graphical user interface toolkit implemented entirely in JAVA(tm). SWANK(tm) provides the companion to Jacl, the Tcl interpreter implemented in JAVA(tm). Thus, Jacl/SWANK(tm) forms the analogous pair to Tcl/Tk and can be used to rapidly script user interfaces. The goal of the design of SWANK(tm) is to provide a toolkit that will be familiar to Tk users, provide a reasonable level of backwards compatibility with Tk, and provide access to the generally greater, as compared to Tk, feature level of the Swing components. SWANK(tm) was, and continues to be, developed with an automatic code-generation technique. Using the JAVA(tm) introspection capabilities available in Jacl, the methods for each Swing class are deduced, and then JAVA(tm) code is automatically written, with a Tcl script, to implement a Tcl/Tk like scripting interface. Implementing SWANK(tm) in this way allows two significant advantages. One, the development of the code was significantly faster than if all the JAVA(tm) code had been hand-written. Second, significant changes in the structure of the code can be made simply by changing the code- generation script, rather than rewriting the JAVA(tm) code that implements the interface to each Swing class. Additional, hand written, JAVA(tm) code provides a variety of utility routines such as the grid, place and pack geometry managers. In the present version there is support for the following Swing components: JButton, JCheckBox, JCheckBoxMenuItem, JComboBox, JDialog, JFileChooser, JFrame, JInternalFrame, JLabel, JList, JMenu, JMenuBar, JMenuItem, JOptionPane, JPanel, JPopupMenu, JRadioButton, JRadioButtonMenuItem, JScrollBar, JScrollPane, JSlider, JSplitPane, JTabbedPane. The following Tk like commands are at least partially implemented: canvas,text, button, label, checkbutton, toplevel, listbox, frame, scale, message, radiobutton, entry, menubutton, menu, pack, bind, grid, wm and winfo commands. SWANK(tm) is available at http://www.nmrview.com/swank/index.html. The license for SWANK(tm) (appended below) grants permission to use, copy modify, distribute and license the software for any purpose. I look forward to receiving feedback on SWANK(tm). This software is copyrighted by Merck & Co., Inc. The following terms apply to all files associated with the software unless explicitly disclaimed in individual files. The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. SWANK(tm) is a trademark of Merck & Co., Inc., Whitehouse Station, NJ, USA JAVA(tm) is a trademark of Sun Microsystems, 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_UNLO
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
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
[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 originally chose JDK 1.1.8 because of this statement at http://dev.scriptics.com/faq/java.html#Q2: "When Tcl Blend is compiled with JDK1.2, it fails a few of the tests, see the known_issues.txt file in the distributions of Tcl Blend for more details." 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] exec command
I have spent some time, and have come up empty. I'm currently using Jacl to try to run batch files on an NT system. However, no matter what I do with that exec command, it merely flips up a cmd.exe window for a moment, and then disposes of it. I tried CALLing and STARTing, and all other sorts of nonsense. Could someone just show me an example of running a batch file from a jacl script? Thanks. - Justin 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
Mo DeJong wrote: > 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. 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.) > > 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. 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. 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] exec command
On Tue, 13 Jun 2000, Levine Justin-p94702 wrote: > I have spent some time, and have come up empty. I'm currently using Jacl to > try to run batch files on an NT system. However, no matter what I do with > that exec command, it merely flips up a cmd.exe window for a moment, and > then disposes of it. I tried CALLing and STARTing, and all other sorts of > nonsense. > > Could someone just show me an example of running a batch file from a jacl > script? It depends on what JDK you are using. If you are having problems with a JDK 1.1 release from Sun, forget about it. JDK 1.2 seems to work better, but that is still not great. Have you tried the IBM JDK? That might work better than the Sun one. Sun does not seem to do a very good job of fixing bugs in the JDK. Just take a look at the exec implementation in Jacl if you want a good scare. By the way, JDK 1.3 has a new exec() API that fixes most of these problems, but it took so long to get in that I never got around to adding it back to Jacl. I filed a bug report with Sun, and it took them someting like 2 years to fix the problem. 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
Mo DeJong wrote:
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.
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);
}
...
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] exec command
Hello, I was using JDK 1.3, but it still wasn't working properly. I gave up and just started using the Runtime class. Thanks. - Justin -Original Message- From: Mo DeJong [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 13, 2000 1:43 PM To: Levine Justin-p94702 Cc: '[EMAIL PROTECTED]' Subject: [Tcl Java] Re: [Tcl Java] exec command It depends on what JDK you are using. If you are having problems with a JDK 1.1 release from Sun, forget about it. JDK 1.2 seems to work better, but that is still not great. Have you tried the IBM JDK? That might work better than the Sun one. Sun does not seem to do a very good job of fixing bugs in the JDK. Just take a look at the exec implementation in Jacl if you want a good scare. By the way, JDK 1.3 has a new exec() API that fixes most of these problems, but it took so long to get in that I never got around to adding it back to Jacl. I filed a bug report with Sun, and it took them someting like 2 years to fix the problem. 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] exec command
On Tue, 13 Jun 2000, Levine Justin-p94702 wrote: > Hello, > > I was using JDK 1.3, but it still wasn't working properly. I gave up and > just started using the Runtime class. > Thanks. I have never tested it under 1.3. The exec class has this huge hack in it to get around the fact that the exec() did not let you tell the system what directory to run the command from. There is no chdir() in Java, so the combo of these things makes it next to impossible to exec() correctly from a JVM. The new exec() API in 1.3 should fix this. Why don't you fix up the ExecCmd.java file for Jacl and send in a patch? 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] exec command
I think, actually, that in 1.2 at least if the System property "user.dir" is
set appropriately that is where the Runtime.exec() takes place. I modified
Interp.setWorkingDir() appropriately (which is called by CdCmd.java):
if (dirObj.isDirectory()) {
workingDir = dirObj;
System.setProperty( "user.dir", dirObj.getPath() );
} else {
throw new TclException(this,
"couldn't change working directory to \""
+ dirObj.getName() + "\": no such file or directory");
}
If this was the only problem with the Runtime.exec() this should solve it.
If I remember correctly, however, it was more complicated than that in early
versions of 1.2. Didn't it hang due to the I/O thread hanging?
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 13, 2000 7:59 PM
> To: Levine Justin-p94702
> Cc: '[EMAIL PROTECTED]'
> Subject: [Tcl Java] Re: [Tcl Java] exec command
>
>
> On Tue, 13 Jun 2000, Levine Justin-p94702 wrote:
>
> > Hello,
> >
> > I was using JDK 1.3, but it still wasn't working properly. I
> gave up and
> > just started using the Runtime class.
> > Thanks.
>
> I have never tested it under 1.3. The exec class has this huge hack
> in it to get around the fact that the exec() did not let you
> tell the system what directory to run the command from. There
> is no chdir() in Java, so the combo of these things makes it
> next to impossible to exec() correctly from a JVM. The new
> exec() API in 1.3 should fix this. Why don't you fix up
> the ExecCmd.java file for Jacl and send in a patch?
>
> 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
>
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] what I now know about the deadlock
Please give me your advice. I've instrumented TclBlend to look for the pattern of execution of MonitorEnter/MonitorExit calls and have learned this. The deadlock seen in my code, and now in the TclBlend regression test AutomaticSignature.test on Solaris with native threads, has these characteristics: 1) Tclblend_Init is never called. Consequently the call of MonitorEnter in that function is never executed. 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of MonitorEnter and MonitorExit: they occur in Exit/Enter pairs in JavaIdleProc, JavaTraceProc, JavaCmdDeleteProc, JavaCmdProc, JavaEventProc, and JavaTimerProc. 3) The sequence of events leading up to deadlock is the following: a) the main thread calls MonitorExit in JavaCmdProc b) the garbage collection thread calls MonitorExit in JavaCmdDeleteProc c) the garbage collection thread calls MonitorEnter in JavaCmdDeleteProc d) the main thread calls MonitorEnter in JavaCmdProc (and blocks) I can think of two solutions to this problem, but I don't know which is "right." SOLUTION 1. Simply remove all remaining calls of MonitorEnter and MonitorExit. SOLUTION 2. Replace all remaining calls of MonitorEnter and MonitorExit by invocations of JAVA_LOCK and JAVA_UNLOCK, respectively (which now have the MonitorEnter and MonitorExit calls removed, but which retain the fiddling with the Java environment). In either case, we should possibly discover why Tclblend_Init is not being called, and fix that. What do you think? Thank you. 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
