How to debug Perl scripts that fork

I use perldb in Emacs for debugging Perl scripts (on Linux). It works great, until I'm debugging a script that forks. If my script executes a "fork", I get this:

######### Forked, but do not know how to create a new TTY. #########

Since two debuggers fight for the same TTY, input is severely entangled.

I know how to switch the output to a different window in xterms and OS/2 consoles only. For a manual switch, put the name of the created TTY in $DB::fork_TTY, or define a function DB::get_fork_TTY() returning this.

O开发者_如何学Cn Unix-like systems one can get the name of a TTY for the given window by typing tty, and disconnect the shell from TTY by sleep 1000000.

I would really like to be able to choose one process (either the parent or the child) and continue debugging that process, while allowing the other to continue unimpeded.

A stretch goal would be a way to unambiguously continue debugging both processes, perhaps opening additional frames in Emacs for control and code windows. But being able to cleanly continue debugging one of them would be a big win.

Is there a way to do this in perldb? I tried to follow the suggestion in this message, but got nowhere with it.

Or do I need some other Perl debugging tool? If the latter, which Perl debugger provides best support for multi-process debugging?

If you have access to the console and a GUI desktop, run the debugger in an xterm window. The perl debugger works pretty seamlessly with xterms, as the warning message alludes to. As new processes are created, the debugger will open new xterm windows, and you can step through execution in any process in any order.

In either case, clearing the inhibit_exit flag is helpful, too, for debugging multi-process programs. Run

o inhibit_exit=0

from the debugger prompt. That way, when you spawn a new process running Perl, and there is no reason to break at any point inside the child process, the child process will not interrupt the debugger with the Debugged program terminated. Use q to quit or R to restart ... message.

Since it's quite likely that you are running under an xterm or similar, you might be being bitten by the Perl debugger's rather narrow view of what an "xterm" is.

It's specifically looking for the string "xterm". It wants to see xterm in the TERM environment variable. Not gnome-terminal. Not xterm-256color. Just xterm.

Run with:

TERM=xterm perl -d ...

to make sure it gets the picture. I only figured that one out after ten minutes of grumping at the Perl debugger.

It seems very happy to spawn tons of xterm windows and doesn't seem very good at cleaning them up when it exits, by the way.

Running the debugger in an xterm window is probably the simplest solution to this problem, but this article describes an alternative approach: There is an undocumented variable $DB::fork_TTY which can assign a particular TTY for forked processes.

Of course, you probably don't want to hard code this kind of logic in your code, so you can create a debugger module that you use only when you need via the -M flag in your perl command.

In this situation, setting up log files (with the PID of the process in each line) may well be the way to go. While not as convenient as the debugger, it's possibly going to be an easy way to understand what's going on with your code.