Skip Menu |
Report information
Id: 132875
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: slaven [at] rezic.de
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



To: perlbug [...] perl.org
Date: Fri, 16 Feb 2018 20:46:23 +0100
From: slaven [...] rezic.de
Subject: Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
CC: srezic [...] cpan.org
Download (untitled) / with headers
text/plain 3.8k
This is a bug report for perl from slaven@rezic.de, generated with the help of perlbug 1.41 running under perl 5.27.9. ----------------------------------------------------------------- Pcore-v0.56.5 cannot be built anymore with 5.27.8 and later. Until 5.27.6 building was possible: http://fast-matrix.cpantesters.org/?dist=Pcore%200.56.5 (No results for 5.27.7 because deps (Type::Tiny) cannot be built here) Running Build.PL fails immediately. It can also be reproduced like this: $ perl5.27.8 -Ilib -MPcore -e1 BEGIN not safe after errors--compilation aborted at /home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-0/lib/Pcore/Core/Event.pm line 3. Compilation failed in require at lib/Pcore.pm line 565. Compilation failed in require at lib/Pcore.pm line 414. BEGIN failed--compilation aborted. ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.27.9: Configured by eserte at Tue Feb 6 19:16:51 CET 2018. Summary of my perl5 (revision 5 version 27 subversion 9) configuration: Commit id: ef80cd9998532b7e2be7823cd9af7ba1198822e5 Platform: osname=linux osvers=3.16.0-4-amd64 archname=x86_64-linux uname='linux cabulja 3.16.0-4-amd64 #1 smp debian 3.16.51-3 (2017-12-13) x86_64 gnulinux ' config_args='-D useshrplib=true -Dprefix=/opt/perl5.27.8-157-gef80cd9 -Dusemymalloc=n -D cc=ccache cc -D usedevel=define -Duse64bit -de' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2' cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='4.9.2' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='ccache cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.19.so so=so useshrplib=true libperl=libperl.so gnulibc_version='2.19' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E -Wl,-rpath,/opt/perl5.27.8-157-gef80cd9/lib/5.27.9/x86_64-linux/CORE' cccdlflags='-fPIC' lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong' --- @INC for perl 5.27.9: /opt/perl5.27.8-157-gef80cd9/lib/site_perl/5.27.9/x86_64-linux /opt/perl5.27.8-157-gef80cd9/lib/site_perl/5.27.9 /opt/perl5.27.8-157-gef80cd9/lib/5.27.9/x86_64-linux /opt/perl5.27.8-157-gef80cd9/lib/5.27.9 --- Environment for perl 5.27.9: HOME=/home/eserte LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/eserte/bin/linux-gnu:/home/eserte/bin/sh:/home/eserte/bin:/home/eserte/bin/pistachio-perl/bin:/usr/games:/home/eserte/devel PERLDOC=-MPod::Perldoc::ToTextOverstrike PERL_BADLANG (unset) SHELL=/bin/zsh
RT-Send-CC: perl5-porters [...] perl.org
On Fri, 16 Feb 2018 19:46:58 GMT, slaven@rezic.de wrote: Show quoted text
> > This is a bug report for perl from slaven@rezic.de, > generated with the help of perlbug 1.41 running under perl 5.27.9. > > > ----------------------------------------------------------------- > Pcore-v0.56.5 cannot be built anymore with 5.27.8 and later. Until > 5.27.6 building was possible: > http://fast-matrix.cpantesters.org/?dist=Pcore%200.56.5 > (No results for 5.27.7 because deps (Type::Tiny) cannot be built here) >
Yes, and Porting/bisect.pl failed accordingly. Show quoted text
> Running Build.PL fails immediately. It can also be reproduced like > this: > > $ perl5.27.8 -Ilib -MPcore -e1 > BEGIN not safe after errors--compilation aborted at > /home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5- > 0/lib/Pcore/Core/Event.pm line 3. > Compilation failed in require at lib/Pcore.pm line 565. > Compilation failed in require at lib/Pcore.pm line 414. > BEGIN failed--compilation aborted. > >
Confirmed. The code is quite complex; I hope the author can look into it. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
From: Dave Mitchell <davem [...] iabyn.com>
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Tue, 20 Feb 2018 14:56:27 +0000
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.6k
On Fri, Feb 16, 2018 at 02:39:53PM -0800, James E Keenan via RT wrote: Show quoted text
> On Fri, 16 Feb 2018 19:46:58 GMT, slaven@rezic.de wrote:
> > Running Build.PL fails immediately. It can also be reproduced like > > this: > > > > $ perl5.27.8 -Ilib -MPcore -e1 > > BEGIN not safe after errors--compilation aborted at > > /home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5- > > 0/lib/Pcore/Core/Event.pm line 3. > > Compilation failed in require at lib/Pcore.pm line 565. > > Compilation failed in require at lib/Pcore.pm line 414. > > BEGIN failed--compilation aborted. > > > >
> > Confirmed. The code is quite complex; I hope the author can look into it.
The proximate cause is the recent switch in order of a sub's signature and attributes; so code like this: sub resolve_sockaddr ( $node, $service, $proto, $family, $type, $cb ) : prototype($$$$$$) { ... } is now a syntax error. *But*, as mentioned in another recent ticket, also tends to throw up lots of spurious warnings, as perl attempts to continue parsing after an error. In this case, the code has a $SIG{__WARN__} handler, which gets called even though the parser is errored. The handler ends a up requiring another module which contains a 'use Foo', which is converted into BEGIN { require Foo; Foo->import }, and since PL_parser->error_count is >0, after compiling the BEGIN sub, perl throws the 'BEGIN not safe after errors' error seen above rather than actually requiring Foo. This can be demonstrated in the following: $ cat /tmp/lib/Foo.pm package Foo; use Bar 'baz'; $ cat ~/tmp/p use warnings; BEGIN { $SIG{__WARN__} = sub { require Foo; }; } $x =; # syntax error %h =~ /a/; # warning $ ./perl -I/tmp/lib ~/tmp/p syntax error at /home/davem/tmp/p line 11, near "=;" BEGIN not safe after errors--compilation aborted at /tmp/lib/Foo.pm line 2. Compilation failed in require at /home/davem/tmp/p line 7. $ So most directly the bug is in the module not adapting to the recent change in syntax of the (experimental) signatures feature, but it also links up with other recent threads on p5p related to 1) what do do about breakage associated with the recent signature change 2) what to do about emitting warnings after an error and also ties in with an older discussion where I suggested that we abandon parsing after any error - there are too many lexer and parser bugs associated with trying to continue. -- "You may not work around any technical limitations in the software" -- Windows Vista license
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
Date: Tue, 20 Feb 2018 17:31:49 +0100
To: Dave Mitchell <davem [...] iabyn.com>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 2.9k
On 20 Feb 2018 22:56, "Dave Mitchell" <davem@iabyn.com> wrote:
Show quoted text
On Fri, Feb 16, 2018 at 02:39:53PM -0800, James E Keenan via RT wrote:
> On Fri, 16 Feb 2018 19:46:58 GMT, slaven@rezic.de wrote:
> > Running Build.PL fails immediately. It can also be reproduced like
> > this:
> >
> > $ perl5.27.8 -Ilib -MPcore -e1
> > BEGIN not safe after errors--compilation aborted at
> > /home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-
> > 0/lib/Pcore/Core/Event.pm line 3.
> > Compilation failed in require at lib/Pcore.pm line 565.
> > Compilation failed in require at lib/Pcore.pm line 414.
> > BEGIN failed--compilation aborted.
> >
> >
>
> Confirmed.  The code is quite complex; I hope the author can look into it.

The proximate cause is the recent switch in order of a sub's signature and
attributes; so code like this:

    sub resolve_sockaddr ( $node, $service, $proto, $family, $type, $cb )
                         : prototype($$$$$$)
    {
        ...
    }

is now a syntax error. *But*, as mentioned in another recent ticket, also
tends to throw up lots of spurious warnings, as perl attempts to
continue parsing after an error.

In this case, the code has a $SIG{__WARN__} handler, which gets called
even though the parser is errored. The handler ends a up requiring another
module which contains a 'use Foo', which is converted into
    BEGIN { require Foo; Foo->import },
and since PL_parser->error_count is >0, after compiling the BEGIN sub,
perl throws the 'BEGIN not safe after errors' error seen above rather than
actually requiring Foo.

This can be demonstrated in the following:

    $ cat /tmp/lib/Foo.pm
        package Foo;
        use Bar 'baz';

    $ cat ~/tmp/p
        use warnings;

        BEGIN {
            $SIG{__WARN__} = sub {
                require Foo;
            };
        }

        $x =;      # syntax error
        %h =~ /a/; # warning

    $ ./perl -I/tmp/lib ~/tmp/p
    syntax error at /home/davem/tmp/p line 11, near "=;"
    BEGIN not safe after errors--compilation aborted at /tmp/lib/Foo.pm line 2.
    Compilation failed in require at /home/davem/tmp/p line 7.
    $


So most directly the bug is in the module not adapting to the recent
change in syntax of the (experimental) signatures feature, but it also
links up with other recent threads on p5p related to

1) what do do about breakage associated with the recent signature change
2) what to do about emitting warnings after an error

and also ties in with an older discussion where I suggested that we abandon
parsing after any error - there are too many lexer and parser bugs
associated with trying to continue

Is it possible we could exempt variable not declared errors from this change?

The biggest value I see of continuing parsing and showing more errors is it allows one to avoid playing whack-a-mole when dealing with such errors. You can find and fix multiple variable uses and etc in one go. If this was still possible then I don't think stopping on the first error of other types would even be noticed....

Yved
Show quoted text
 
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
To: demerphq <demerphq [...] gmail.com>
Date: Wed, 21 Feb 2018 09:31:11 +0000
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 1.1k
On Tue, Feb 20, 2018 at 05:31:49PM +0100, demerphq wrote: Show quoted text
> Is it possible we could exempt variable not declared errors from this > change? > > The biggest value I see of continuing parsing and showing more errors is it > allows one to avoid playing whack-a-mole when dealing with such errors. You > can find and fix multiple variable uses and etc in one go. If this was > still possible then I don't think stopping on the first error of other > types would even be noticed....
Well, the rationale for for bailing out on the first error is that at that point the lexer and parser are in an unknown and possibly inconsistent state. Continuing to parse after that point to detect any further errors is likely to trigger bugs. In fact fuzzing over recent years has shown that there is a large supply of such bugs, and I doubt that we would ever detect and fix them them all (perl's lexer being over 12K LoC). So continuing is bad enough; continuing and possibly emitting further warnings is even worse, as that could trigger a call to a $SIG{__WARN__} and thus you're now actually executing code while the interpreter is in an inconsistent state. -- Fire extinguisher (n) a device for holding open fire doors.
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
Date: Wed, 21 Feb 2018 11:17:04 +0100
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.4k
On 21 Feb 2018 17:31, "Dave Mitchell" <davem@iabyn.com> wrote:
Show quoted text
On Tue, Feb 20, 2018 at 05:31:49PM +0100, demerphq wrote:
> Is it possible we could exempt variable not declared errors from this
> change?
>
> The biggest value I see of continuing parsing and showing more errors is it
> allows one to avoid playing whack-a-mole when dealing with such errors. You
> can find and fix multiple variable uses and etc in one go. If this was
> still possible then I don't think stopping on the first error of other
> types would even be noticed....

Well, the rationale for for bailing out on the first error is that at that
point the lexer and parser are in an unknown and possibly inconsistent
state. Continuing to parse after that point to detect any further errors
is likely to trigger bugs.  In fact fuzzing over recent years has shown
that there is a large supply of such bugs, and I doubt that we would ever
detect and fix them them all (perl's lexer being over 12K LoC).

So continuing is bad enough; continuing and possibly emitting further
warnings is even worse, as that could trigger a call to a $SIG{__WARN__}
and thus you're now actually executing code while the interpreter is in an
inconsistent state.

But none of that reasoning applies to undeclared lexicals. Such code would compile fine without use strict.

So again, could we exempt that class of error from your proposed change? If so I think most people would not even really notice something had changed.

Yves
Show quoted text

From: Dave Mitchell <davem [...] iabyn.com>
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Date: Wed, 21 Feb 2018 11:50:27 +0000
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
To: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 820b
On Wed, Feb 21, 2018 at 11:17:04AM +0100, demerphq wrote: Show quoted text
> But none of that reasoning applies to undeclared lexicals. Such code would > compile fine without use strict. > > So again, could we exempt that class of error from your proposed change? If > so I think most people would not even really notice something had changed.
So If I understand you right, we would stop immediately on first encountering most errors, but some errors would be exempted from this and we would continue parsing. Exempted errors would be things that don't affect parsing state, like, as you suggest, "Global symbol "$x" requires explicit package name", while syntax errors and similar would immediately stop. That seems plausible, -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz
Date: Wed, 21 Feb 2018 13:04:16 +0100
To: Dave Mitchell <davem [...] iabyn.com>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.6k
On 21 Feb 2018 19:50, "Dave Mitchell" <davem@iabyn.com> wrote:
Show quoted text
On Wed, Feb 21, 2018 at 11:17:04AM +0100, demerphq wrote:
> But none of that reasoning applies to undeclared lexicals. Such code would
> compile fine without use strict.
>
> So again, could we exempt that class of error from your proposed change? If
> so I think most people would not even really notice something had changed.

So If I understand you right, we would stop immediately on first
encountering most errors, but some errors would be exempted from this and
we would continue parsing.

Yeah, I'm thinking anything that is only an error under 'use strict' would be allowed to pile up, but anything that is an error regardless of 'use strict' would stop further parsing.

Show quoted text

Exempted errors would be things that don't affect parsing state, like, as
you suggest, "Global symbol "$x" requires explicit package name", while
syntax errors and similar would immediately stop.

Yep, exactly. I wouldn't necessarily go as far as 'doesnt affect parsing state' as I imagine that might be a can of worms. Basing the rule on whether something would be allowed without strictures would seem to provide the value we try to provide with our current policy while being a simpler policy.

Show quoted text

That seems plausible,
Show quoted text

If so then I imagine that your proposal will not be perceived as a patch that takes away something useful but rather it will be perceived as something that makes things outright better. 

I believe many perl programmers "tune out" much of the error messages we show as many of them are garbage caused by the current policy. The main exception being that it can be very useful to see a list of the mistyped vars in a script with one compilation run.

Yves


Show quoted text

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Wed, 21 Feb 2018 01:31:28 -0800, davem wrote: Show quoted text
> On Tue, Feb 20, 2018 at 05:31:49PM +0100, demerphq wrote:
> > Is it possible we could exempt variable not declared errors from this > > change? > > > > The biggest value I see of continuing parsing and showing more errors > > is it > > allows one to avoid playing whack-a-mole when dealing with such > > errors. You > > can find and fix multiple variable uses and etc in one go. If this > > was > > still possible then I don't think stopping on the first error of > > other > > types would even be noticed....
> > Well, the rationale for for bailing out on the first error is that at > that > point the lexer and parser are in an unknown and possibly inconsistent > state. Continuing to parse after that point to detect any further > errors > is likely to trigger bugs. In fact fuzzing over recent years has > shown > that there is a large supply of such bugs, and I doubt that we would > ever > detect and fix them them all (perl's lexer being over 12K LoC). > > So continuing is bad enough; continuing and possibly emitting further > warnings is even worse, as that could trigger a call to a > $SIG{__WARN__} > and thus you're now actually executing code while the interpreter is > in an > inconsistent state.
$SIG{__WARN__} seems awfully similar to BEGIN blocks. It probably shouldn’t be allowed when PL_error_count is positive. (Instead, a error gets thrown.) But that might be too intrusive a change. Though what Yves suggests is a plausible alternative. -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org