[Tcl-bugs] [ tcl-Bugs-597936 ] leak in new thread allocator

[<no...@so...>]

Bugs item #597936, was opened at 2002-08-20 17:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=597936&group_id=10894

Category: 39. Memory Allocation
Group: None
Status: Open
Resolution: None
Priority: 9
Submitted By: miguel sofer (msofer)
Assigned to: miguel sofer (msofer)
Summary: leak in new thread allocator

Initial Comment:
The following script runs forever. With the new Tcl_Obj
allocator (USE_THREAD_ALLOC) its memory grows slowly
but steadily; all seems fine with the standard allocator.

  lappend auto_path /CVS/thread/unix
  package require Thread
  proc spawn {} {
      global i
      after 10 spawn
      thread::create "puts [incr i]"
      flush stdout
  }
  
  set i 0
  spawn
  vwait forever
  

----------------------------------------------------------------------

>Comment By: miguel sofer (msofer)
Date: 2002-08-22 12:12

Message:
Logged In: YES 
user_id=148712

Aarghh ... looking at the wrong place, disregard previous
comment! Leak is from

==7385==    at 0x400467C4: malloc (vg_clientfuncs.c:100)
==7385==    by 0x805D430: TclThreadAllocObj (in
/CVS/tcl_SF_clean/unix/tclsh)
==7385==    by 0x8055F87: Tcl_NewObj (in
/CVS/tcl_SF_clean/unix/tclsh)
==7385==    by 0x8066EDB: Tcl_CreateInterp (in
/CVS/tcl_SF_clean/unix/tclsh)
==7385==    by 0x4023F0D8: NewThread (in
/CVS/thread/unix/libthread2.4.so)
==7385==    by 0x40250166: thread_wrapper (vg_libpthread.c:521)
==7385==    by 0x4004B7E0: do__apply_in_new_thread_bogusRA
(vg_scheduler.c:2023)


----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2002-08-22 12:03

Message:
Logged In: YES 
user_id=148712

Mmhh ... seems to be related to tclsh not cleaning up
properly on exit - in particular, the encoding stuff. I
could detect where the leak is with valgrind; the leaked mem
was created from

==7357==    at 0x400467C4: malloc (vg_clientfuncs.c:100)
==7357==    by 0x805D430: TclThreadAllocObj (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x8055F87: Tcl_NewObj (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x80657C8: TclpInitLibraryPath (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x8089693: TclFindEncodings (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x8087C28: Tcl_FindExecutable (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x805508A: Tcl_Main (in
/CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x8054EE7: main (in /CVS/tcl_SF_clean/unix/tclsh)
==7357==    by 0x4029E627: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==7357==    by 0x8054DE1: strcpy@@GLIBC_2.0 (in
/CVS/tcl_SF_clean/unix/tclsh)


----------------------------------------------------------------------

Comment By: Andreas Kupries (andreas_kupries)
Date: 2002-08-22 11:47

Message:
Logged In: YES 
user_id=75003

Hm. Could it be that the pool of objects associated with a 
thread is not freed after a thread is done. Or maybe they are 
just shuffled around into the global pool. In both situations we 
would have an ever-growing list of free objects. Either as true 
leak, or simply because we keep creating thread-object-pools 
but never using the allocated objects.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2002-08-22 11:10

Message:
Logged In: YES 
user_id=148712

Note that this has nothing to do with [after], the following
shows the same behaviour:

lappend auto_path /CVS/thread/unix
package require Thread
set i 0
while 1 {
    thread::create "puts [incr i]"
}



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=597936&group_id=10894