At 11:07 PM -0500 11/18/06, John E. Malmberg wrote:
>This fixes a minor issue on VMS where the Perl debugger incorrectly detects
>that it is forked.
>
>On OpenVMS, programs are run under the PID of the DCL shell, so the PID does
>not change from program to program.
True, but you do get a new pid when you spawn a subprocess, which I
believe is what PERLDB_PIDS is designed to track.
I think the symptom you noticed is more due to differences in
environment scope than in pid handling. The debugger uses the
presence of anything in $ENV{PERLDB_PIDS} as an indication that the
current debugger is running in a child process. That doesn't always
work on VMS because setting the %ENV hash from within Perl creates
(under default settings) a supervisor mode logical name that persists
after Perl exits, whereas on unixy systems, setting something in %ENV
does not persist after Perl exits.
When the debugger exits normally, there is clean-up code that should
tear down PERLDB_PIDS in any case, but if there is a crash too
serious to handle or you break out of the debugger, then the setting
could persist and a second run of the debugger will think it is a
child process. Here's how easy it is to trigger that:
$ perl -d
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
<CTRL-Y>
$ perl -d
Daughter DB session started...
<CTRL-Y>
$ show logical PERLDB_PIDS
"PERLDB_PIDS" = "93631->93631" (LNM$PROCESS_TABLE)
>
>--- /rsync_root/perl/lib/perl5db.pl Sat Jul 8 13:56:37 2006
>+++ lib/perl5db.pl Sat Nov 18 17:49:05 2006
>@@ -1317,9 +1317,21 @@
> # We're a child. Make us a label out of the current PID structure
> # recorded in PERLDB_PIDS plus our (new) PID. Mark us as not having
> # a term yet so the parent will give us one later via resetterm().
>- $pids = "[$ENV{PERLDB_PIDS}]";
>- $ENV{PERLDB_PIDS} .= "->$$";
>- $term_pid = -1;
>+
>+ my $env_pids = $ENV{PERLDB_PIDS};
>+ $pids = "[$env_pids]";
>+
>+ # Unless we are on OpenVMS, all programs under the DCL shell run under
>+ # the same PID.
>+
>+ if (($^O eq 'VMS') && ($env_pids =~ /\b$$\b/)) {
>+ $term_pid = $$;
What I think this is saying is that if the pid of the current process
is in the list, then consider ourselves the parent and do not add
ourselves to the list. It seems to me these two things should be
separated and clarified:
1.) If the current process matches the *first* element in the list,
take that as an "I am the parent" indication equivalent to the
nonexistence of $ENV{PERLDB_PIDS}. One way to do that would be to
add a check before the current logic in which we simply clobber
$ENV{PERLDB_PIDS} in this case, and then let the current logic
continue to function as is.
2.) Never add a pid to the list if it already exists, perhaps
issuing a warning if we do see a duplicate.
>+ }
>+ else {
>+ $ENV{PERLDB_PIDS} .= "->$$";
>+ $term_pid = -1;
>+ }
>+
> } ## end if (defined $ENV{PERLDB_PIDS...
> else {
Go ahead and take another crack at the patch if you want to.
BTW, the reason the new lib/perl5db.t test is failing on VMS is, as
far as I can tell, unrelated. It appears at first blush that the TTY
override is not working and it is waiting for input from the console
that it never gets.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
