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 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 ()
> > #16 0xee9993a4 in _start ()
> >
> > ----------------------------------------------------------------
> > 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
----------------------------------------------------------------
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
