I have a perl script that "usually" works well. It is executed in this way.The code prints to STDOUT:
$ perl mycode.pl input_file.txt > output.txtNow one time when it take certain file (smaller than usual one), my code above just "hang in there". It doesn't die off and not giving segfault message or any error message as per normal error message we encounter.
My question is what's is the best way to debug find out the cause of this hanging problem?
- make sure you've added "or die" (or "&& die" for system() calls) clauses to every instance where system interface functions are called (open, chdir, etc.)
- use strict; use warnings;
- change to 'perl mycode.pl input_file.txt 2&>output.txt' and run 'tail -f output.txt' from another console window to see where it stops
- post your code here
Don Wilde
"There's more than one level to any answer."
Along the same lines you could change your print statements to warn, which will give you information as to where you are in the script.
Where and how should I put this line in my script?
Auto-flush STDOUT ($| = 1;)
If you're on Linux, use the strace utilitiy to tell you what your script is doing while it hangs. Either run
strace -f perl mycode.pl input_file.txt > output.txtor start your script normally, wait till it hangs, find out the PID of the script process and execute
strace -f -pstrace prints to STDERR, so you'll see the strace output normally in your terminal while STDOUT still gets written to the output file. It will tell you what the process is doing on a system call level. To find out where it hangs at the perl level you could execute it in the debugger and step through until it hangs.
perl -d mycode.pl input_file.txt > output.txtAll dogma is stupid.
Similar utilities for other platforms are ktrace and kdump for BSDen (including OS X), and truss for Solaris.
They're all handy if you're really stumped, but go for tossing in a few debugging prints to STDERR and running with -d first.