Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Second potential memory leak in Tcl8.4b1 using thread allocator

3 views
Skip to first unread message

Sven Sass

unread,
Jul 26, 2002, 12:13:09 PM7/26/02
to
Hey folks,

small correction for the first problems test script:
for { set i 0 } { $i < 100000 } {incr i} {lappend a ""; unset a}
should, as far as I am concerned not increase memory usage (noticably) at
all. BTW, this works fine (append or set):
for { set i 0 } { $i < 100000 } {incr i} {append a ""; unset a}

We have corrected this (don't know the details, let me know if you are
interested), but there seems to be another problem. The environment for this
test can be found in one of my earlier postings concerning Tcl performance
with threads. Basicly it reads as follows: Use one process with two threads,
each holding its own interpreter, the interpreter is compiled using the new
thread allocator.

In our environment each thread is terminated after N execution of Tcl
scripts and a new thread (and interpreted) is being instantiated. We do this
to ensure that global variables used by sloppy Tcl scripts do not consume
memory. The problem with the new allocator mechnism seems to be that the
first thread is freeing the memory in the finalization function properly but
each following thread does not clear it's own (thread local) memory. We
tracked this down to the static "once" variable which causes this behaviour.
Without the once (and probably the reason why it is implemented) memory will
presumably be freed multiple times causing GPF. Please note, that currently
we have only checked this for Windows environments, but the code suggests
this will also occur on Linux platforms.

Actually I had not the time yet to make up a good testing scenario for you
to easily reproduce this. I guess that the AOL people either instantiate the
threads only once and destroy them only upon closing of the process or they
do not have a script which is only being executed once and does not act as
server so this behaviour never occured to them.

Altough the situation of threads being created and destroyed within one
server process might not be too likely I think this behaviour might need
some attention - what do you guys think?

Best regards,
Sven

0 new messages