develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Broken stack traces from use statements.

Thread Previous | Thread Next
Ovid via perl5-porters
January 13, 2022 10:45
Re: Broken stack traces from use statements.
Message ID:
For those who want to know exactly what's going on and don't want to wade through the diff or tests:

$ mkdir lib/{A,B,C}

And in each of those, add this:

package Apack;use Bpack;1;
package Bpack;use Cpack;1;
package Cpack;my $i = 0;
while ( my ( $package, $file, $line ) = caller( $i++ ) ) {    push @Cpack::callers, "$file:$line";}1;

And then create

#!/usr/bin/env perl
use lib 'lib';use Apack;use Data::Dumper;print Dumper( \@Cpack::callers );

If you have a patched Perl, you get this:

$VAR1 = [          'lib/',          'lib/',          'lib/',          'lib/',          'lib/',          'lib/',          '',          '',          ''        ];

That's perfectly sane and you can figure out what's going on (though I confess I don't know why some stack frames are repeated).
For an unpatched Perl, you get something like this:

$VAR1 = [          'lib/',          'lib/',          'lib/',          'lib/',          'lib/',          'lib/',          '',          'lib/',          'lib/'        ];

I cannot use that stack trace for debugging.
I have verified the buggy behavior all the way back to 5.8.9.
The patch which reverted the fix notes the following:

commit c0d05305c156c83e4f9f3a207451b3175fbb7f24 (HEAD)Merge: c6b2e294d8 79f75eaa71Author: David Mitchell <>Date:   Mon Apr 27 22:04:23 2020 +0100
    [MERGE] Revert BEGIN { caller() } fixups
    These commits were intended to fix a problem with stack backtraces    reporting wrong file and line numbers in nested use's.
    A side-effect of the commits was to fix the package name returned by    caller() too; but quite a few distributions were relying on the old    behaviour.
    So for now, revert to the old behaviour and re-address after 5.32.0 is    released.
    The reverted commits are:
    v5.31.6-141-gf2f32cd638 avoid identical stack traces    v5.31.9-122-gee428a211d docs: clarify effect of $^H, %^H, ${^WARNING_BITS}    v5.31.9-162-gad89278aa2 fixup to "avoid identical stack traces" - try 2

I don't know which distributions were failing or why, but having a few distributions making it harder for all Perl developers to debug their programs seems backwards.
What can we do to get this fixed?
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile development 

Buy my book! -

 On Thursday, 13 January 2022, 06:05:07 CET, demerphq <> wrote: 

This subject has come up multiple times and is a source of deep frustration for me, and deep confusion for the many non-perl developers who work on perl code at

This was fixed by Dave Mitchell in f2f32cd638746f538da6db804dab6dd54e654f30

This patch was then reverted in merge commit c0d05305c156c83e4f9f3a207451b3175fbb7f24.

Thus stack traces are *still* broken. I am looking at many examples right now and it is impossible to debug what is happening. I cannot post the work examples but the patch referenced includes examples from its tests.

Can we please fix this once and for all? We are running patched perl's at work so that we can fix this (without any sign of any related fallout!), and every time we release a new perl we have to reapply f2f32cd638746f538da6db804dab6dd54e654f30. When the people who build new perls forget then we end up with mass confusion amongst our devs.

Perl has a really bad name amongst the devs we hire, this one of the reasons. Can we please please please FINALLY DO SOMETHING about this? Perl has so many weird ways to establish a dependency and this bug makes it almost impossible to debug non-trivial cases even for an expert class perl dev like myself. 

I beg of you, do not let another perl get released with this bug in place!


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About