On Fri, 20 Oct 2000, Daniel Wickstrom wrote:
> The TclList.getLength method converts indexListObj to a TclList object
> which uses an underlying Tcl_Obj to hold the internal rep. At the end
> of this case statement, it returns leaving indexListObj with no
> references. The jvm garbage collects indexListObj, but the underlying
> Tcl_Obj is left stranded and results in a memory leak.
>
> -Dan
What does your src/tclblend/tcl/lang/CObject.java finalize()
method look like? I thought the last round of patches left
that ptr dangling on purpose. I have not has time to
look at the patches your guys are using so I am not
sure what is going on. I think what we need to do in the
short term is to implement a patch that will send a
Tcl_Obj that gets freed back to the Tcl interp using
the thread safe event queue. That way we can free the
object up back in the Tcl thread and it will not core
dump like it would if we freed it up in the JVM GC
thread. After we have something (anything) working
we can hack around with the various ref count
solutions to see if we can find one that passes
all the tests and does not leak memory.
We also need to make the Tcl Blend Notifier thread
safe. I think time would be better spent focusing
on that right now instead of fighting ref counting.
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
