Tcl Source Code

From clt: 

[cygwin on WinNT]

The script below (attached) seems to crash reliably for
me after somewhere around 340 iterations.  In the
project where I found the problem (much too big and
messy be of much use in diagnosis I think), I was
creating threads at much greater intervals (e.g 30
seconds) and getting crashes with fewer iterations than
in this test script, so maybe it is just related to the
memory leaks.

I've yet to try checking out new code and recompiling.

Cheers,
Julian

Logged In: YES 
user_id=7549

Patch committed to HEAD as what the patch fixes is "a good 
thing".  I don't know if this fixes this issue entirely.

Could someone do a fresh update and let me know?

File Added - 35840: patch.txt

Logged In: YES 
user_id=7549

The attached patch seems to fix the problem :)

All win channel drivers had a good 'going over' to make sure 
they cleanly exit their worker threads.

Does this fix the problem for you guys, too?  Like Julian, I 
witnessed the same lock-ups, but couldn't put my finger on 
exactly where it was coming from.

Following my instinct, I looked at how the standard channels 
where initialized/shutdown in each thread created.  I noticed 
that in the shutdown phase the reader and writer threads 
(console channel driver) where terminated rather than allowed 
a clean exit.  Knowing this was a big problem in the pipe 
driver for the read thread, I followed the same structure and 
made all worker threads the same.

Now I don't get the lock-up.  process handle count is stable 
all the way to 2000 and probably beyond, but didn't want to 
wait around.  Thread count doesn't grow either which means 
all handles are being recycled properly :)

Logged In: YES 
user_id=7549

Seems to be related to the console channel driver as far as I 
can tell.  I think it's rather odd that there is a reader and writer 
thread for it when a console handle is already a waitable 
object...  I cleaned-up the exit condition so TerminateThread() 
is avoided, and noticed a marked improvement, but this 
needs more study.

Logged In: YES 
user_id=95086

URKS? traceroute??? 
Can you please avoid any execs in the worker thread 
and see if the error persists? 
I'm sorry for all this fuss, but It seems to me that we're  
hitting some other, thread-unrelated, problem.

Logged In: YES 
user_id=598324

worse news... I've now received the "can't create a new 
thread" error from an application that uses a simple 
pool of 3 threads instead of continually creating and 
destroying.  
The application had simply stalled without apparent 
error, and when I typed thread::create "puts test" at the 
prompt I got the error. 
The pool is extremely simple - there should usually be 
at most 2 threads in use, and after the initial pool 
creation it doesn't use thread::create at all.  It just has 2 
timers that every 30 seconds send a message to the 
first free thread to do a traceroute.  This may also be the 
source of a mystery error in another app I have where 
after hours of use it just stops communicating with 
another process.

Logged In: YES 
user_id=598324

hmm.. after running the while loop... it gives an error at 
around iteration 350 or so.
Then I can interactively run:
thread::create "puts x"
as many times as I want, but then if I run:
thread::create "puts x; thread::wait"
I can no longer run thread::create "puts x"  at all without 
the error.

Logged In: YES 
user_id=598324

No, the simple while loop gives the same "can't create 
new thread" error.

For some reason I seem to be able to run the line:
thread::create "puts xxx"
interactively as many times as I want after the while 
loop has terminated... 
Try to run it in a for or while loop again - and it 
performs one iteration only.

Logged In: YES 
user_id=148712

Is this dependent on the async mechanism? What happens with

package require Thread
set i 0
while 1 {
    thread::create "puts [incr i]"
}

Logged In: YES 
user_id=598324

CVS'ed with the tag HEAD a few hours ago and rebuilt 
tcl and thread - problem still exists, though now 
consistently getting slightly higher iterations from the 
crash.tcl script than before,  400 - 600 though this may 
well be related to a drop in the number of other apps 
running on my machine.
used mingw, configured as follows:
tcl:   --enable-threads --prefix=e:/tcl
thread: --enable-threads  --with-tcl=e:/tcl/lib --
prefix=e:/webpub/pvt/pcm_sys/tcl

Error occurs on both dual & single CPU machines - also 
occurs in thread2.2 
One time I got 3 junk characters as final output from 
the test script instead of the usual "can't create a new 
thread" error being raised. I don't know if it's even 
slightly relevant, but the chars were a rightwards 
pointing triangle,r & I.

Logged In: YES 
user_id=75003

Update: I got crashes without Windows Task Manager now 
too, but in much higher ranges: 1691 iterations for example.

Logged In: YES 
user_id=148712

Andreas succesfully reproduce the crash under strange
circumstances: it will only crash with "Can't create a new
thread"  if the Windows Task Manager is open. Memory reqs
are fairly constant, there doesn't seem to be a leak there.

This was built using cygwin for configure/make, compiled
with MSVC++. The new allocator was *not* used.

My guess is that the mingw build of the original report was
hitting both this bug and also the new allocator bug #597936.

File Added - 29458: crash.tcl