Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

control-C to "jumpstart" windows process

by jimt (Chaplain)
on Oct 18, 2006 at 14:16 UTC ( #579081=perlquestion: print w/ replies, xml ) Need Help??
jimt has asked for the wisdom of the Perl Monks concerning the following question:

Okay, we're stumped. I will fully preface this by saying that we vaguely think this is a windows problem, as opposed to a perl problem. But it's the perl program where the error manifests, so I'm posting here. I'm a unix guy, not a windows guy, so I'm clueless.

Basically, we have several scripts that we run in the windows terminal. From time to time (and yes, this is a mandelbug), the program stops giving us output to the terminal screen. First time this happened, we thought the program was hanging, so tried to kill it with a control-c. And, surprise surprise, it actually lept back to life and spit out the last of its output. Turns out the thing had finished a while ago.

And that's how it works. Sometimes (we're not sure when), the program stops giving us output, but a control-C will "wake it up" and cause it to continue on and display. We're not doing anything fancy with signal handlers or anything in the scripts. This also appears to have started manifesting itself in scripts that didn't previously exhibit the behavior.

So, in short, WTF? Has anyone encountered anything like this? What should we do now?

Update w/more info: It's perl 5.8.8 built for MSWin32-x86-multi-thread, binary build 817 [257965] provided by ActiveState, built Mar 20 2006 17:54:25. Microsoft Windows [Version 5.2.3790] is the banner at the top of the terminal, Its Windows Server 2003 Enterprise Edition, Service Pak 1.

Comment on control-C to "jumpstart" windows process
Re: control-C to "jumpstart" windows process
by blazar (Canon) on Oct 18, 2006 at 14:34 UTC
    So, in short, WTF? Has anyone encountered anything like this? What should we do now?

    As is often said... hard to say without seeing the code. Do you have or can prepare a minimal example exhibiting this behaviour? Personally I've never met anything like this, and I'm running perl (also) under Windows...

      disclosure: jimt and I are working together, and are collectively stumped by this problem. Here is some sample code, but it doesn't mean anything at all.

      my $t0 = new Benchmark; print 'Doing stuff... '; .. do a bunch of stuff with, say, DBI .. my $t1 = new Benchmark; print 'Done; This took: ' . timestr(timediff($t1, $t0)) . "\n";

      As mentioned above, this is an occasional problem, in that, it manifests on occasion. I wish it were a constant and replicable problem.

      If we can't find the cause of this problem, is there any way we can get around it? We could have our script send out a "CTRL-C" if we could somehow figure out that.. "well, its been a while and the process should have completed by now." Of course, if we are wrong, and the process is still going on, then we would end up killing the process. Not good.

      In other words, this is a serious pain in the arse, and our hope is that someone else has been bitten by it and has found a reason and/or a cure for it.

      --

      when small people start casting long shadows, it is time to go to bed
        which version of perl? which version of windows? etc...monks can be more helpful when pertinent details are provided.
        you could try the old "turn of buffering" trick.
        $|=1;
        the hardest line to type correctly is: stty erase ^H
        Echoing the other monks, more info would mean more help to you!

        I'm going totally off the top of my head here, but I'm guessing you're trying to output something w/o a newline directly before something is getting processed?

        Ex:
        $x=9999999; print "Test1"; while($x--){0}
        Even though Test1 is passed to STDOUT, the while loop is processed before you see any output.

        If that's the case, try tossing a newline in there. (Again, I'm going off the top of my head here.) Perl won't display the output buffer until a newline is present, the operation holding it up produces output, or the operation is done.

        -inno
Re: control-C to "jumpstart" windows process
by BrowserUk (Pope) on Oct 18, 2006 at 15:37 UTC

    If you right mouse and click 'Mark', on a running CMD window, the output will be 'frozen' until you make your selction with the mouse and complete the operation. If the operation is never completed, then the output remains frozen. ^C will abort the operation and the output will continue. A second ^C would abort the program.

    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.

    In eather case, the title of the window will have the word "Mark" or "Select" prepended to it indicating the state of the terminal session, and hitting the escape key will abort the operation and let the output continue.

    This sounds like it might be the cause of your problem. If hitting Escape does not clear the problem, then it's not, and this post is a waste of both our time.


    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.

      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;

      (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.

      - tye        

      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        

        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.
      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!!

Re: control-C to "jumpstart" windows process
by cdarke (Prior) on Oct 18, 2006 at 16:36 UTC
    A ctrl-C sends a message, CTRL-C-EVENT, to the process group (where > 1 processes are using the same console). This should kill the process unless a console handler is set (SetConsoleCtrlHandler C API). It seems likely that ActiveState traps this, since you get a "Terminated on signal SIGINT" under normal circumstances (or it might be using the C RTL signals?).
    You can send a CTRL-C using API GenerateConsoleCtrlEvent, but, like everyone else, I don't know why these hangs should occur (buffering was my first thought too).
    Just a thought, how are you launching the programs, through cmd.exe, Windows Explorer, or some other way?
Re: control-C to "jumpstart" windows process
by chargrill (Parson) on Oct 18, 2006 at 18:42 UTC

    It sounds like the quick-edit mode might be the culprit, so I won't comment on that. However, I notice no one has questioned your use of the windows command window.

    That's what I'm doing - you're a self-stated unix guy - Why are you using the DOS box?

    Please let me wholeheartedly recommend installing cygwin. It's free, and much more importantly it comes with bash (or ash or zsh or csh or even pdksh) and most importantly, much more friendly to 'eunuchs' than windows CMD.exe . (And to my knowledge, there's no funny-business going on with errant mouse clicks in the window.)



    --chargrill
    s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)

      I have cygwin and use it a lot. I don't use bash (too many things it just doesn't do well under Win32). But I brought up the "bash" prompt since you didn't appear to actually know anything, just make claims about what you don't know. (:

      The "bash prompt" has exactly the same behavior with regard to mark/select mode and pausing output. You can even turn on "QuickEdit" mode for it.

      - tye        

        Sorry, I tend to forget my experiences while working on Windows rather quickly - and, it's been a few months... My usual mode of working within cygwin was to immediately start up X with an xterm, which definitely doesn't have a quick-edit mode and therefore doesn't display that behavior. Having left that out of my earlier statement makes it misleading, so apologies.



        --chargrill
        s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
Re: control-C to "jumpstart" windows process
by lyklev (Pilgrim) on Oct 18, 2006 at 18:52 UTC
    I don't know if this is causing your problem, but output to console on Win32 is really messed up if you run the script by just typing its name (without 'perl'). Try for example echoing a lot of stuff and redirecting it to a file. A couple of lines works, but if you try to redirect a lot of output, only a part will get redirected.

    If this is an option for you, you can either execute the script with 'perl', so

    perl somescript.pl
    or you can convert the script to a 'bat'-file using pl2bat. It wraps your Perl script in a 'bat'-file.

    I am interested if this will do the trick.

Re: control-C to "jumpstart" windows process
by Shikko (Initiate) on Aug 09, 2007 at 20:49 UTC
    Here's hoping this bump will get some responses...

    jimt, I have the exact same problem as you describe, using:
    Windows XP SP2 [Version 5.1.2600] perl, v5.8.8 built for MSWin32-x86-multi-thread with 25 registered pat +ches Binary build 817 [257965] provided by ActiveState http://www.ActiveSta +te.com Built Mar 20 2006 17:54:25
    - the script starts to run, creating data.
    - after some amount of time, the script pauses in execution. The process is still listed under the process tab, but its processor time counter is not increasing.
    - 20 hours later, I hit control-c and get a printed status update on the console (from 7 hours after execution started) and the script starts creating data again.

    The script is doing a lot of file I/O on local storage, but no DBI calls. My boss says he's had this happen with ActiveState before, too, in a script that was doing both a bunch of DBI work and file I/O.

    Did you ever find a cause/solution to this problem? Any help would be appreciated in getting my actual processing time as close to my estimate of four days as possible. :)

    Cheers!

    ---Chaos, fear and disorder. My work here is done.

      Next time it happens, before you use ^C, check the titlebar of the console window and see if the first word there is either 'Mark' or 'Select'. If it is, hit the Esc key and that word should disappear and the process continue.

      If that works, learn (or instruct whomever is doing it), to be more careful when switching to the command session window using the mouse.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://579081]
Approved by Corion
Front-paged by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (8)
As of 2014-08-27 23:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (253 votes), past polls