Test ran to completion with Sun's JDK 1.1.8 on Solaris, no errors.
Mo DeJong wrote:
Now don't panic, but it looks like we have uncovered
a serious JVM bug in Sun derived JVMs = 1.2 that
nukes the Tcl/Java reflect table. Lots of
thanks go to Thomas McKay for tracking down and
creating a
Am I missing something? I do not see this behavior in the 8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 1 "$x toString"
unset x
update
}
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
Error in bgerror: invalid
va0x1"
^^
Error in bgerror: invalid command name "bgerror"
Is that not the same error you encountered?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 12:16 AM
Mo DeJong wrote:
It depends on what you are doing. In regular Java, you need to know
what the type of the objects you put into a vector are because
you need to cast them back up to something when you pull them
out of the vector. TclJava is no different, you just put the
class you would cast
Here's the test case. There are three files. First I'll tell you what's in them, then
I'll
tell you what's perplexing about the case. Total for the three files is 92 lines of
code.
blah.tcl: the Tcl script that often gets a weird error like 'invalid command name
"java0x3"'.
Four.java: the
So far, I have not been able to do so. I see it in StoryServer, but have not even
been able to reproduce it under the Tcl shell yet. And the StoryServer template is
many thousands of lines, after processing INCLUDEs.
Mo DeJong wrote:
Could you create a small script and a .java file that
This one appears to be different. Vignette StoryServer 5.0, Tcl 8.2.3,
TclBlend 1.2.5, JDK 1.1.8, SunOS 5.6. TclBlend patched as described in
my last post. Little flexibility to upgrade to more recent versions of
anything.
Every thread stacktrace that seems relevant is below. The
So, pardon my desperation, but are you gentlemen going to save my job and give
me a TclBlend 1.2.5 patch to try out?
Jeff Sturm wrote:
Mo DeJong wrote:
Ahh, but Tcl provides a portable locking layer when compiled with
threads support. That is what I am sugesting we use for the mutex.
OK,
I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't matter in this
context," because that seems to fix my problem.
Dr Wes Munsil wrote:
Please give me your advice.
I've instrumented TclBlend to look for the pattern of execution of
MonitorEnter/MonitorExit calls and ha
g TclBlend.
I also think removing all instances of MonitorEnter and MonitorExit from the
TclBlend code should not do any harm.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 13, 2000 9:50 PM
To: [EMAIL PROTECTED]
Mo DeJong wrote:
On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
1) Tclblend_Init is never called. Consequently the call of MonitorEnter
in that function is never executed.
That does not seem right. The Tclblend_Init method should be
invoked by Tcl during the load command (like load
The patch I ended up with to solve the Solaris deadlock issue combines
Jiang Wu's patch and the removal of all MonitorEnter and MonitorExit
calls. The diffs between TclBlend 1.2.5 and my version are at
http://idd.com/~wes/tclblendpatch. Note also that the class
tcl.lang.NativeLock may now be
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 a
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
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
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
[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
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
18 matches
Mail list logo
