Without seeing your code, we can only guess.

You can for example have opened a filehandle to the name -:

perl -we "open F,'-';while (<F>){}"
[download]

or you can have opened a filehandle to the console (Windows version):

perl -we "open F,'CON:';while (<F>){}"
[download]

Or your program might have used a weid combination of fork() and exec() and one of the children crashed.

Without showing us any of your (reduced) code, all you can do is investigate yourself.

The program is around 10,000 lines and I don't know exactly which part of it is the culprit. Sometimes the problem happens twice a day. In other times, just once a week.

I thought it might be a stability issue when calling certain perl built-in functions. I'm running on Windows XP with ActivePerl 5.8.8 installed.

The program is around 10,000 lines and I don't know exactly which part of it is the culprit.

Perhaps a few debug statements with time stamps in a log file would help

sub logger{
$time=localtime();
print LOGFILE "$time : @_\n";
}
sub parseElement{
logger("I am in UR parseElement starting");
...
[download]

that way you should be able to isolate where the issue arises

Is it possible that XP is hibernating or going into standby?

Are other applications affected at the same time?

Perhaps you could add a sig handler to your code. Something like the sig handler here:

#!

use Carp;
use strict;
use warnings;

$SIG{INT}=\&CtrlC;

sub CtrlC {
    $SIG{INT}=\&CtrlC;
    Carp::carp('Caught a CTRL/C');
     };

sub mySub {
    for (1..10) {
        <STDIN>;
         };
     };

    for (1..10) {
        <STDIN>;
         };
    mySub();
    exit;
[download]

When it hangs again, just give it a ctrl/c and see where it carps from.

What is your evidence that pressing a key on the keyboard causes your program to resume?

If your program is waiting until there is input available form the keyboard and resuming when it is available without consuming it, then it is likely that you are mistaken about it not trying to "listen" to an input, though it would have to be something other than simply reading from <STDIN>, which would consume the input.

One option would be to run it under strace or truss, if you are so lucky as to be running on a *nix system. That might show you what it is waiting on.

update: It seems there is a trace program for Windows also.

Obviously, the problem is on line 3!

Seriously, though, you've already gotten a few serious responses, and I couldn't help but make the joke, since it's quite often people ask us to find the problem without showing the code. (Normally, though, we get to tell them that the problem is on line 42.)

</snarky-mode>

Next time you encounter the pause, before you hit a key or click in the window, check the titlebar and see if it has the word "Select" as the first word.

BrowserUk: Sounds like something simple enough for me to do. I will check that, definitely. Thanks.

Mind if I ask what does that mean? How do I simulate such a condition whereby "Select" appears as the first word on the titlebar?

Just to add:
After pressing any key, I don't have to follow up with a Return key, unlike in <STDIN>. It's just one hit on the keyboard and that's it, the program resumes. Pressing Shift or Ctrl alone won't do, but it accepts Backspace. Pressing Ctrl+C will not terminate the program with a "Terminating on signal SIGINT(2)" message like you would normally see. Instead, it resumes the program too just like most of the other keys.

If your cmd.exe windows have "Quick edit" mode enabled, then if you (or somebody) left-clicks in the window (say to bring it to the top of the window stack), then it can select (highlight for copy & paste), one or more characters. A side effect of this is that output to the screen is suspended until the C&P is completed by right-clicking.

And if the program is regularly outputting to the screen, then undisplayed output will accumulate until the internal buffer fills, at which point the next write attempt will block until the select state is ended. Effectively suspending the program. The select state can be ended by right-clicking in the window so completing the copy & paste operation.

It can also be ended by typing any key, which abandons the C&P and allow the blocked write to succeed and the program to continue. Ie. Exactly the symptoms you've described.

The Quick-edit mode is very useful, but it can be confusing if you are not aware of it, or its affects.

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."