A Perl 3 bug in the debugger

[pemungkah]

I recently posted about this on my blog, but it's worth a quick post here too.

There's a fun little bug in the debugger, which you can see like this. Create a dumb little script. Anything will do.

#!/bin/perl
use strict;
use warnings;

print "we";
print "just";
print "need";
print "something";
print "to";
print "list";

Now let's start up the debugger.

perl -d zz.pl

Loading DB routines from perl5db.pl version 1.77
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(zz.pl:5):    say "we";
  DB<1>

All as expected, but now:

  DB<1> l 1.2
1.2     use strict;
  DB<2> l
2.2     use warnings;
3.2     use feature 'say';
4.2     
5.2:    say "we";
6.2:    say "just";
7.2:    say "need";
8.2:    say "something";
9.2:    say "to";

That's kind of unexpected, but it gets better!

  DB<2> l 1.1.3.5
1.1.3.5     use strict;
  DB<3> l
2.1     use warnings;
3.1     use feature 'say';
4.1     
5.1:    say "we";
6.1:    say "just";
7.1:    say "need";
8.1:    say "something";
9.1:    say "to";

Why does this happen? well it goes back to commit a687059cbaf, which is the one that moves the debugger into lib in Perl 3. The pattern used to capture the line number specification is (\d\$\.)+, which matches all kinds of things, including floating-point numbers, IPv4 addresses, and other junk. The overall pattern used to parse the l command arguments changes over time, but that basic match to extract a "line number" never does.

You may be thinking, "yeah, okay, I see that, but why does the debugger show the floating-point line number?" The reason is that the line number spec is captured as a string. THe debugger stores the source code of the current file in an array whose name is not a valid Perl variable name, and uses the line number spec captured by the l command to index it.

When Perl indexes an array, the index value is converted to an integer if possible, because array indexes have to be integers. The line spec we have is captured and stored as a string, so when we try to index the source array with it, "1.22" becomes the integer 1, and we find line 1. The command uses the value of the index variable (remember, that's still a string!) to print the line number, and so we end up with a floating-point line number.

Now, when we run the bare l command, the string "1.22" is still in the list command's "last line listed" variable, and Perl simply takes that variable and adds 1 to its contents to look for the next line. Since the contents are a string that looks like a floating point number, Perl converts it to a float, adds 1.0 (so we don't downgrade it from a float), and assigns that back to the current line number,so we get lines 2.22, 3.22, and so on.

I've submitted a patch to fix this for 5.40, but it's pretty surprising that we've had this bug for 32 years!

[LanX]

Nice catch... :)

I can reproduce that on Win with 5.032001, but not the magic appearance of your

> 3.1     use feature 'say';

and the followin say statements, which are also not in the source you've shown.

I also looked into @DB::dbline which is aliased to @{"::_<zz.pl"} to be sure, and there was no "feature say".

Could it be you debugged another file, where you swapped print with say ?

FWIW: Those internal vars are explained in https://perldoc.perl.org/perldebguts#Debugger-Internal-Variables

update

> but it's pretty surprising that we've had this bug for 32 years!

Frankly, the debugger does so may weirdly elaborated things ...

... I assume most who saw this just thought it's a yet unknown feature to be explored.