This seems like the most likely explanation to me.

My initial guess was that the problem was output buffering coupled with something causing the script to hang toward the end. But testing that theory doesn't show the buffered output being flushed for such a case.

One thing that I find very annoying is that, by default, Windows considers very small mouse motions to be "drags". Since the typical configuration has the button mounted on a movable mouse, it is quite hard for me to consistently press a mouse button without moving the mouse pointer a couple of pixels. So, by default, my mouse "clicks" often become "drags", which have results much different than were desired.

So every Windows system (with a mouse) that I end up working with for more than a few hours get the following changes applied:

my $Reg;
use Win32::TieRegistry( TiedRef => \$Reg, Delimiter => "/", ArrayValue
+s => 1 );
$Reg->{"CUser/Control Panel/Desktop//DragHeight"}= 10;
$Reg->{"CUser/Control Panel/Desktop//DragWidth"}= 10;
$Reg->{"CUser/Control Panel/Mouse//DoubleClickHeight"}= 10;
$Reg->{"CUser/Control Panel/Mouse//DoubleClickWidth"}= 10;
[download]

(They default to just 4 pixels -- and I think some of them used to default to just 2 pixels.)

A similar change might make your "bug" less frequent.

Or, if you have enabled "Quick edit" mode, then left-dragging, or even just left clicking the mouse will make a selection and so freeze the output until the operation is completed. Again ^C will abort the operation and unfreeze the output.

It's completely OT, but let me thank you (many) x 3 times for mentioning "Quick edit" mode and was blaming the prompt command console all the time for requiring me those additional right clicks and menu selections. Now it behaves like a... good behaved terminal! Thanks again!!

I was very hopeful about this, but it doesn't appear to be the case. I'm basing this off of the fact that when I click on a window, it does indeed freeze the output, but it also appears to freeze the program. I tested this with a simple little loop that just increments a counter. When I enter select mode, the counter freeze. When I exit select mode, the counter resume where it left off.

It appears that our program is continuing to run when we encounter the glitch, it just doesn't display to the screen. So I think it's something different. But this may be the right track.

My testing shows "$x++ while 1" continues to consume 100% of the CPU even when I have text in the console window selected. Trying to write output to a frozen window will certainly freeze the program (as your test showed, I assume, based on the fact that you report being able to see the counter increment).

- tye        

That's a good point - I had my little test program constantly printing out, and that did indeeded freeze. I tweaked it to only print out every 10 passes through the loop, and sure enough that counter did continue to increment properly until it hit the next print, then it froze. So that does imply that it it continues to work and only locks up on output.

Quick edit mode was enabled, which I just shut off. I'll keep my fingers crossed that this was indeed the solution.

If you are printing to STDOUT without having turned off the buffering, then the program will continue producing output and will not be blocked until the buffer has filled.

If the process completes before the buffer fills, then clearing the mark or select state will allow the ouput to finish though the process may have finished some time earlier.

The output will appear contiguous in both cases because of the buffering. No output is discarded, it is simply buffered and displayed once the freeze thaws.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Note that output to STDOUT defaults to "line-buffered" mode (except on older versions of Win32 Perl where the default was unbuffered), so this would only apply to a single line of output (based on "\n", not a single row of the terminal window).

- tye