Perl 5.10.0 bugreport: wrong debugger interaction with 'n' single stepping and a panic

[Heiko Eißfeldt <heiko@hexco.de>]

Dear porters,

the 'n' command in the debugger of Perl 5.10.0 (and earlier) has a
weird behaviour sometimes.

Despite the description 'n' does not step over subroutines, when being
used with the grep, map, and sort operators in __some__ calling
patterns.

First I suspected a problem in perl5db.pl and DB.pm, and made a patch.
But later I tested more methodically, and came to the conclusion that
the core handles things a bit inconsistently (and needs the patch).

So this is a bug report.

To illustrate what I mean, here is my test script. I am not able to
give a real automated *.t testscript, only a manual one.

You need to start it with the debugger and step through with the 'n'
command.


I have prefix-commented the cases, that do not work as expected, with

	'n' does not step over code block

and those that work with

	works


Please note that in one testcase for map, I got a panic from the
interpreter.

=======================
use strict;
use warnings;

# Testcases for debugger single stepping with 'n'
# 'n' does not step over subroutines always.

# sort OPERATOR
# works
print 'sort 1. ', (join q{,}, sort               qw(a z b y)), "\n";
# 'n' does not step over code block
print 'sort 2. ', (join q{,}, sort { $a cmp $b } qw(a z b y)), "\n";
# 'n' does not step over code block
print 'sort 3. ', (join q{,}, sort(::mycmp       qw(a z b y))), "\n";


# map OPERATOR
# 'n' does not step over code block
print 'map  1. ', (join q{,}, map({ uc($_) } qw(a z b y))), "\n";

###### panics with 5.10.0
# 'n' does not step over code block?
#print 'map  2. ', (join q{,}, map(::myuc qw(a z b y))), "\n";


# grep OPERATOR
# works
print +(0 < scalar grep(sub { $_ == 9 }, (1..10))) ? "found\n" : "not
found\n";
# 'n' does not step over code block
print +(0 < scalar grep     { $_ == 9 }  (1..10))  ? "found\n" : "not
found\n";


use List::Util qw(first);
# works
print +(0 < scalar first(sub { $_ == 9 }, (1..10))) ? "found\n" : "not
found\n";
# works
print +(0 < scalar first     { $_ == 9 }  (1..10))  ? "found\n" : "not
found\n";


use List::MoreUtils qw(any);
# works
print +(0 < scalar any(sub { $_ == 9 }, (1..10))) ? "found\n" : "not
found\n";
# works
print +(0 < scalar any     { $_ == 9 }  (1..10))  ? "found\n" : "not
found\n";


sub mycmp
{
	return $a cmp $b;
}

sub myuc
{
	return uc($_[0]);
}
==============================

So, in summary
these cases do not work with 'n' stepping in the debugger, 
instead the execution is interrupted in the code block.
o   grep { $_ == 9 }
o   sort { $a cmp $b }
o   sort (::mycmp ...)
o   map  { uc($_) }

map/grep/sort operators do not use the same parameter types for code
blocks, which would be nice.
o   grep (sub { $_ == 9 }, ...)
o   sort (::mycmp ...)
o   map  (::myuc ...) panics


There is a thread on Perlmonks http://www.perlmonks.org/?node_id=709679
and perl.debugger called 'accelerated stepping', but this is the
essence.


I would like to get some pointers to the core,
and hints how code blocks and code references are treated
with regard to debugger interaction, especially when
they are parameters of grep/map/sort.


Thanks, and best regards, heiko
--

---

Follow-Ups from:

Heiko Eißfeldt <heiko@hexco.de>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---