In a message dated 4/6/05 5:23:58 PM, [EMAIL PROTECTED] writes:


Am 06.04.2005 um 22:31 schrieb Dossy Shiobara:
> Zoran, if you have some time, could you try building Tcl 8.4.0 with the
> threaded memory allocator and see if your tests show whether the same
> memory growth problem exists or not?
>
> If not, test 8.4.1, etc. until you find the point where the leak was
> introduced.� Then, we can examine the diff between the two versions and
> try to identify where the leak was introduced?
>

I can confirm that 8.4.1 does appear to work correctly.
I yet have to sweep upwards. Somewhere between the 8.4.1 and 8.4.5
the things start to go wrong since the 8.4.5 is last one I tested
"from the top down".

But... my laptop battery is giving up and this has now to wait
until tommorow... Anyways, it seems we are heading somewhere.



It turns out theres an undocumented Tcl_GetMemoryInfo call in Tcl.  The only user is AOLserver's "ns_info pools" command which uses it to get a list of lists of per-bucket memory usage for each thread.  Since it turns out you can load libnsd to get the ns_info command (also undocumented), you can try this:

shell# bin/tclsh8.5
% load lib/libnsd.so
% ns_info pools;  ... look at output on zippy memory usage ...
% ... run test ...
% ns_info pools;  ... look again ...

If things add up, you should see bloat in the "shared" pooled where memory from those threads winds up on exit and could explain the growth.   If it doesn't add up, perhaps there's a leak -- maybe the Tcl zippy memory allocator structures themselves which are allocated directly with malloc are leaking.

Curious what you find...

-Jim
2">

Reply via email to