#3465 thread::release on win32 does not release all memory

obsolete: 8.4.19
closed-out-of-date
9
2012-11-19
2006-07-12
Anonymous
No

The original usenet posting -
All 5 messages in topic - view as tree

From: usenet....@googlemail.com - view profile
Date: Tues, Jul 11 2006 11:01 am
Email: usenet....@googlemail.com
Groups: comp.lang.tcl
Not yet rated
Rating:
show options

Reply | Reply to Author | Forward | Print | Individual
Message | Show original | Report Abuse | Find messages
by this author

I am running tcl 8.4 on Windows XP Pro 2002, SP2.
The simple script below fails on thread::create right
under 12,000
iterations.

Attempts to create any more threads fail in the same
shell once a call
to
thread::create fails.
Restarting tclsh and rerunning seems to work fine
within the limits
mentioned
above.

Would anyone know the reason this would fail?

---------------
tclsh
package require Thread
set i 1
while { 1 } {
set id [thread::create]
thread::release $id
puts -nonewline " $i "
flush stdout
update
incr i

}

From: David Gravereaux - view profile
Date: Wed, Jul 12 2006 12:17 pm
Email: David Gravereaux <davyg...@pobox.com>
Groups: comp.lang.tcl
Not yet rated
Rating:
show options

Reply | Reply to Author | Forward | Print | Individual
Message | Show original | Report Abuse | Find messages
by this author

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

joe,

I ran your script this time and I see what's going on :)

The Tclsh process runs out of virtual memory space!
Not committed
memory.. True VM allocations. I even tried the old
fashioned way with
thread::wait and thread::unwind that I personally know
for a fact do not
leak handles.. The issue is not a handle leak. The
issue is not
committed memory (apparently), but it appears that for
each thread
created, a slice of VM is given to it permanently and
that slice isn't
recouped (though it appears to have been uncommitted).

Joe, insert your script as a new bug. There's
something going on that's
a bit deeper than proper handle management.

the Old way (that has the same behavior):

package require Thread
set i 1
while { 1 } {
set id [thread::create {thread::wait}]
thread::send -async $id {thread::unwind}
puts -nonewline " $i "
flush stdout
update
incr i

}

Discussion

  • Zoran Vasiljevic

    Logged In: YES
    user_id=95086

    Hi!

    This is I believe the side-effect of the thread memory allocator
    which is known to be memory greedy as it was optimized on
    speed and not memory usage. I have seen this behaviour on
    all Unices as well, not only Windows. Although it seems that on
    Unices is far less visible. I'm able to create and terminate about
    30.000 threads and the VM usage increases about 1MB.

     
  • Zoran Vasiljevic

    • status: open --> open-remind
     
  • Zoran Vasiljevic

    Logged In: YES
    user_id=95086
    Originator: NO

    I will still leave this open but will try to replace
    the greedy Tcl memory allocator with just calls
    to regular system allocator and see if this helps.
    If yes then we can think of making an alternate
    allocator for Tcl OR even just simple use the
    system-level one as those beasts are more
    thread-aware today as they have been 5 year ago.

     
  • Zoran Vasiljevic

    Perhaps this is a problem related to memory leak in the teardown logic.
    I will need to investigate the memory leak problem first.

     
  • Don Porter

    Don Porter - 2012-04-24
    • assigned_to: vasiljevic --> dgp
    • status: open-remind --> pending-out-of-date
     
  • Don Porter

    Don Porter - 2012-04-24

    Testing the trunk (2.6.8) and thread-2-7-branch (2.7b1)
    on Linux with the submitted test scripts I see no leaks
    with the Tcl trunk.

    Would be good for someone to confirm on Windows.

     
  • Don Porter

    Don Porter - 2012-04-24
    • priority: 5 --> 9
    • status: pending-out-of-date --> open
     
  • Don Porter

    Don Porter - 2012-04-24

    ok then

     
  • Don Porter

    Don Porter - 2012-11-13
    • assigned_to: dgp --> mistachkin
     
  • Don Porter

    Don Porter - 2012-11-19

    Joe, did we decide this one is out of date?

    That is, the leak problems on Windows are
    already fixed? Thanks for closing this ticket
    if you confirm.

     
  • Joe Mistachkin

    Joe Mistachkin - 2012-11-19

    Used the provided test script on Windows 8 and created 16K threads. Total memory used by the process was around 2MB. Therefore, no leak.

     
  • Joe Mistachkin

    Joe Mistachkin - 2012-11-19
    • milestone: --> obsolete: 8.4.19
    • status: open --> closed-out-of-date
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks