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);
� �� /*
� � � * Perform proper cleanup of things done in TclpGetAllocCache.
� � � */
� �� if (initialized) {
� � � �� pthread_key_delete(key);
� � � �� initialized = 0;
� �� }
}
If you modify it too read:
void TclpFreeAllocCache(ptr)
� �� void *ptr;
{
� �� extern void TclFreeAllocCache(void *);
� �� TclFreeAllocCache(ptr);
}
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...
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, possible just a slot or two in static memory. While it's possible one could write super clean code that could carefully determine that no threads would ever access a slot again and enable a safe pthread_delete_key, in practice you can't guarantee that nor is there much value in an attempt. This is especially the case in environments like Tcl and AOLserver where folks are encouraged to link in their own code which can execute in any order.
It appears this code isn't in the HEAD version of Tcl -- it must have been sneaked into some branch.
-Jim
2">
- Re: [AOLSERVER] Leaky AS/Tcl memory allocator -- Tcl 8.4.... Jim Davidson
- Re: [AOLSERVER] Leaky AS/Tcl memory allocator -- Tcl... Zoran Vasiljevic
- Re: [AOLSERVER] Leaky AS/Tcl memory allocator --... Dossy Shiobara
- Re: [AOLSERVER] Leaky AS/Tcl memory allocato... Zoran Vasiljevic
