Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#3580 Memory leak with thread::transfer

obsolete: 8.4.14
Don Porter

I am developing project using Tcl + Thread (BitTorrent tracker). At first I tried to use model where main thread after accepting new connection (using
socket -server) transfers connection socket to free thread using thread::transfer. But testing of this model reveals slow memory leak (about 1Mb/5min with requests rate about 100 req/sec). Using Tcl memory debugging (Tcl and Thread built with --enable-symbols=mem) and memory command I found that memory leaks after each thread::transfer call. This observes on latest Tcl/Threads versions as well (tcl8.4.14 and thread2.6.5) compiled on Solaris 9/i386 using GCC 3.3.2.

Is this a known issue ? Is thread::transfer requires some extra dealing with transferred filedescriptors before or after transfer ?

This is a small test:


package require Thread

proc transfer {channel} {
global tid

puts [memory info]
thread::transfer $tid $channel
thread::send -async $tid "close $channel"

proc accept {channel client_addr client_port} {
after idle [list transfer $channel]

set tid [thread::create -joinable thread::wait]

socket -server accept 9999


Field "current bytes allocated" increased by 32 bytes after each incoming connection.


  • Logged In: NO

    Sorry, I forgot to include a e-mail. My e-mail is oleg@vsi.ru.

  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES
    Originator: NO

    I am not able to repro this bug using valgrind 3.2.1 on Linux x64. Perhaps it is because it is being properly freed at exit, just not in the interim use?

  • Logged In: NO

    So "current bytes allocated" output by [memory info] doesn't increase after each new connection in your tests ?

  • Logged In: YES
    Originator: NO

    What you experience might be a problem in Tcl core
    that badly handles std channels. I'm loking at that
    at this moment.

    It appears to leak std channels on every thread
    creation and exit. I haven't examined your code
    but will do that later on when I find out what the
    damn is happening with those channels and why do
    they leak.

    This is considered to be a very problematic point
    in Tcl design (handling of std channels when
    building thread-enabled Tcl library).

  • Logged In: YES
    Originator: NO

    vasiljevic, if this issue will be resolved some day - it will be good. Are there any solutions or recommendations for this case now ?

  • Don Porter
    Don Porter

    • priority: 5 --> 9
    • assigned_to: vasiljevic --> dgp
  • Don Porter
    Don Porter

    Problem is that ThreadTransfer() doesn't free
    the resultPtr that it allocs.

  • Don Porter
    Don Porter

    Fixed for Thread 2.6.8+.

  • Don Porter
    Don Porter

    • status: open --> closed-fixed