Zoran Vasiljevic wrote:
Am 07.04.2005 um 10:38 schrieb Zoran Vasiljevic:
the leak is gone. Now I have to rewind the stack and try to
figure out what did the author(s) *really* wanted to do.
Seems that somebody was cleaning up some state but cleaned
up much to much...
...
BTW, the problem was
Well, this doesn't appear to explain my memory problems:
# LD_LIBRARY_PATH=`pwd` ./tclsh
% info patchlevel
8.4.6
% lappend auto_path /usr/local/src/thread/unix; package require Thread
2.6.1
% exec ps -p [pid] -o pid,vsz,rss,args
PID VSZ RSS COMMAND
23736 5176 1824 ./tclsh
% for {set i 0} {$i
Am 07.04.2005 um 14:34 schrieb Jim Davidson:
Ugh -- this isn't good. In general, there is very little reason one
should ever need to call pthread_delete_key -- that deletes the index
in the per-thread slots where the pointer to the actual memory for
each thread is held. The key itself is tiny, po
In a message dated 4/7/05 4:48:52 AM, [EMAIL PROTECTED] writes:
This is the one. More precisely the unix/tclUnixThrd.c
as of 8.4.7 (and later) looks like:
void TclpFreeAllocCache(ptr)
void *ptr;
{
extern void TclFreeAllocCache(void *);
TclFreeAllocCache(ptr);
/*
* Pe
Am 07.04.2005 um 10:38 schrieb Zoran Vasiljevic:
the leak is gone. Now I have to rewind the stack and try to
figure out what did the author(s) *really* wanted to do.
Seems that somebody was cleaning up some state but cleaned
up much to much...
I have opened Tcl Bug #1178445 to track this issue.
I h
Am 07.04.2005 um 05:34 schrieb Jeff Hobbs:
OK, looks like Tcl 8.4.7 introduced the leak. Here's my test
run against Tcl 8.4.6:
I would suspect this patch from Kenny / Mistachkin (applied by me):
2004-07-20 Jeff Hobbs <[EMAIL PROTECTED]>
* generic/tclEvent.c: Correct threaded obj al
