From patrickmclot@gmail.com

I am running ActiveState Perl (v5.26.1) on a 64-bit Windows 7 installation.
I checked on perlMonks and it turns out this bug is in Strawberry Perl
64-bit as well. It runs fine on 32-bit Windows and 64-bit Linux. The
file that reproduces the bug is attached as "small".

Cheers,
Patrick

From patrickmclot@gmail.com

small

From @jkeenan

On Sun, 26 Aug 2018 22​:34​:18 GMT, patrickmclot@​gmail.com wrote​:

I am running ActiveState Perl (v5.26.1) on a 64-bit Windows 7 installation.
I checked on perlMonks and it turns out this bug is in Strawberry Perl
64-bit as well. It runs fine on 32-bit Windows and 64-bit Linux. The
file that reproduces the bug is attached as "small".

Cheers,
Patrick

Let me see if I correctly understand your sample program (re-attached with a .pl extension).

You open a (global) filehandle to read from a file -- that file being the program itself.

For each line read you call a subroutine, parser(), which takes the line as input but then does nothing with it, since all the subroutine does is to print "Hello, world".

If I run it on Linux, all I get is​:

#####
$ perl 133477-small.pl
"?) at 133477-small.pl line 10, <INFILE> line 1."#!perl
#####

I confess that I don't understand the point of such a program -- but I concede that that doesn't explain why it crashes on Windows (which I don't have available).

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

From @jkeenan

133477-small.pl

The RT System itself - Status changed from 'new' to 'open'

From @sisyphus

The sample program crashes on x64 Strawberry Perl 5.26.0, but on x64 Strawberry Perl 5.28.0 it produces output of​:

Can't locate object method "parser" via package "#!perl" (perhaps you forgot to
load "#!perl"?) at small.pl line 10, <INFILE> line 1.

I believe that's the expected output - and therefore I would suggest that this bug has already been fixed.

Cheers,
Rob

From @xenu

On Sun, 26 Aug 2018 21​:31​:09 -0700
"sisyphus@​cpan.org via RT" <perlbug-followup@​perl.org> wrote​:

The sample program crashes on x64 Strawberry Perl 5.26.0, but on x64 Strawberry Perl 5.28.0 it produces output of​:

Can't locate object method "parser" via package "#!perl" (perhaps you forgot to
load "#!perl"?) at small.pl line 10, <INFILE> line 1.

I believe that's the expected output - and therefore I would suggest that this bug has already been fixed.

Cheers,
Rob

The crash was caused by the fact that the name of the filehandle starts
with 'INF', change it to anything else, the code will stop crashing.

While the code crashes only on Windows, it also behaves weirdly on other
platforms. For example, the following code executed with perl 5.26.2 on
dragonfly or linux​:

open INFILE, '<', \'foo';
while (<INFILE>) {
  warn 'bar';
}

outputs "bar at a.pl line 3, <INFILE> line 0.000000.". Note that the line
number is a float.

The following commit has fixed those problems​:

commit 559a021
Author​: David Mitchell <davem@​iabyn.com>
Date​: Tue May 16 16​:30​:13 2017 +0100

  sprintf​: handle sized int-ish formats with Inf/Nan
 
  The code path taken when int-ish formats saw an Inf/Nan was to jump to the
  floating-point handler, but then that would warn about (valid) size
  qualifiers. For example before​:
 
  $ perl -we'printf "[%hi]\n", Inf'
  Invalid conversion in printf​: "%hi" at -e line 1.
  Redundant argument in printf at -e line 1.
  [%hi]
  $
 
  After this commit​:
 
  $ perl -we'printf "[%hi]\n", Inf'
  [Inf]
  $
 
  It also makes the code simpler.

However, the commit message doesn't say anything about crashing or float
line numbers, which makes me think that the fix was accidental.

I wonder if the bug was actually fixed or maybe it was just hidden.

CC-ing Dave to get his opinion.

From @iabyn

On Wed, Aug 29, 2018 at 04​:24​:33PM +0200, Tomasz Konojacki wrote​:

However, the commit message doesn't say anything about crashing or float
line numbers, which makes me think that the fix was accidental.

I wonder if the bug was actually fixed or maybe it was just hidden.

CC-ing Dave to get his opinion.

It appears to be a combination of bugs, all of which were fixed
by my extensive reworking of Perl_sv_vcatpvfn_flags() for 5.28.0.

It's caused by the warn code doing​:

  Perl_sv_catpvf(aTHX_ sv, ", <%" SVf "> %s %" IVdf,
  SVfARG(PL_last_in_gv == PL_argvgv
  ? &PL_sv_no
  : sv_2mortal(newSVhek(GvNAME_HEK(PL_last_in_gv)))),
  (IV)IoLINES(GvIOp(PL_last_in_gv)));

i.e. doing the 'C' variant rather than the 'perl' variant of sprintf,
so it gets its args from a va_list rather than from an array of SVs.

Handling the special-cased %SVf format (which actually expands to "%-p"
triggered a code path where a variable, argsv, got left set on later %'s.
This meant that the later %IVdf (i.e. %ld) was using the "INFILE" SV as
its arg rather than the intended IoLINES(). Which then triggered a second
bug with the poor handling of INF in integer formats.

I haven't fully diagnosed this (life is too short), but I suspect my 100+
commits that worked on Perl_sv_vcatpvfn_flags() will have fixed all the
issues here.

--
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
  -- old farmers' sayings #14

From @sisyphus

The sample program crashes on x64 Strawberry Perl 5.26.0, but on x64 Strawberry Perl 5.28.0 it produces output of​:

Can't locate object method "parser" via package "#!perl" (perhaps you forgot to
load "#!perl"?) at small.pl line 10, line 1.

I believe that's the expected output - and therefore I would suggest that this bug has already been fixed.

Also, if the sample program is modified slightly to call a parser sub that outputs each parsed line, it produces the expected output without crashing:

C:\>perl -v

This is perl 5, version 30, subversion 0 (v5.30.0) built for MSWin32-x64-multi-thread

C:\>perl small.pl
> #!perl
>
> use strict;
> use warnings;
>
>
> open INFILE, '<', $0;
>
> while (<INFILE>) {
>       chomp;
>       parser($_);
> }
>
> sub parser {
>       print "> $_[0]\n";
> }
>
>
> __END__

Definitely seems like this ticket can be closed?

Definitely seems like this ticket can be closed?

Seems like that to me.