Mailing List Archive: Perl: porters

[perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz

Index | Next | Previous | View Threaded

perlbug-followup at perl

Jul 5, 2012, 10:46 PM

Post #1 of 8 (129 views)
Permalink

[perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz

# New Ticket Created by (Andreas J. Koenig)
# Please include the string: [perl #114008]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114008 >

git bisect
----------
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
5f9f83be9cdcd54449f7f40db078fe367d780475
We cannot bisect more!

sample fail reports
-------------------
The bug manifests in an endless loop with CPU being consumed
(t/20-Problems/000-Correct_Defaults.t). The few fails that arrived at
cpantesters were triggered because a CPU limit was hit. The diagnostics
are then a bit irritating:

http://www.cpantesters.org/cpan/report/236c15be-c319-11e1-8cac-f06608f5d1fc

perl -V
-------
Summary of my perl5 (revision 5 version 17 subversion 0) configuration:
Commit id: 5f9f83be9cdcd54449f7f40db078fe367d780475
Platform:
osname=linux, osvers=3.2.0-3-amd64, archname=x86_64-linux
uname='linux k83 3.2.0-3-amd64 #1 smp thu jun 28 09:07:26 utc 2012
x86_64 gnulinux '
config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.16.0-150-g5f9f83b/165a
-Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des
-Ui_db -Uuseithreads -Uuselongdouble -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
ccversion='', gccversion='4.7.1', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib
/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.13'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_MALLOC_WRAP PERL_PRESERVE_IVUV
PERL_USE_DEVEL
USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES
USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
Built under linux
Compiled at Jul 6 2012 07:00:05
@INC:
/home/src/perl/repoperls/installed-perls/perl/v5.16.0-150-g5f9f83b/165a/lib/site_perl/5.17.0/x86_64-linux
/home/src/perl/repoperls/installed-perls/perl/v5.16.0-150-g5f9f83b/165a/lib/site_perl/5.17.0
/home/src/perl/repoperls/installed-perls/perl/v5.16.0-150-g5f9f83b/165a/lib/5.17.0/x86_64-linux
/home/src/perl/repoperls/installed-perls/perl/v5.16.0-150-g5f9f83b/165a/lib/5.17.0
.

--
andreas

nick at ccl4

Jul 6, 2012, 5:28 AM

Post #2 of 8 (123 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On Thu, Jul 05, 2012 at 10:46:26PM -0700, Andreas J. Koenig via RT wrote:

> f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
> 5f9f83be9cdcd54449f7f40db078fe367d780475
> We cannot bisect more!

For information:

$ git log f041cf0f9c6469c41de8b73d5f7b426710c3ff8b^! 5f9f83be9cdcd54449f7f40db078fe367d780475
commit 5f9f83be9cdcd54449f7f40db078fe367d780475
Author: Rafael Garcia-Suarez <rgs [at] consttype>
Date: Tue May 22 17:23:20 2012 +0200

Fix mktables bug due to the previous overload fix

Due to the previous patch, perl can't generate the operator for .= in
package Property anymore (because fallback is '0' in that package), so
we need to work around that; this patch implements the least intrusive
workaround possible.

commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
Author: Rafael Garcia-Suarez <rgs [at] consttype>
Date: Tue Mar 20 09:17:02 2012 +0100

Lookup overloaded assignment operators when trying to swap the arguments

This is in the case where we search for an overloaded operator when
passing the AMGf_assign flag (we're executing an assignment operator
like +=).

At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
not passed, we first try to look up the overload method corresponding
to the assignment operator, then the normal one if fallback is
authorized. However, if this fails, when trying later to find
overload magic with the arguments swapped (if AMGf_noright is not
passed), this procedure was not used and we looked up directly the base
operation from which the assignment operator might be derived.
As a consequence of what an operator like += might have looked
autogenerated even when fallback=>0 was passed.

This change only necessitates a minor adjustment in lib/overload.t,
where an overloaded += method wasn't corresponding semantically to the
overloaded + method of the same class, which can be seen as a
pathological case.

so effectively the two commits are the for the same change.

Nicholas Clark

doy at tozt

Jul 6, 2012, 7:38 AM

Post #3 of 8 (127 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On Fri, Jul 06, 2012 at 01:28:49PM +0100, Nicholas Clark wrote:
> On Thu, Jul 05, 2012 at 10:46:26PM -0700, Andreas J. Koenig via RT wrote:
>
> > f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
> > 5f9f83be9cdcd54449f7f40db078fe367d780475
> > We cannot bisect more!
>
> For information:
>
> $ git log f041cf0f9c6469c41de8b73d5f7b426710c3ff8b^! 5f9f83be9cdcd54449f7f40db078fe367d780475
> commit 5f9f83be9cdcd54449f7f40db078fe367d780475
> Author: Rafael Garcia-Suarez <rgs [at] consttype>
> Date: Tue May 22 17:23:20 2012 +0200
>
> Fix mktables bug due to the previous overload fix
>
> Due to the previous patch, perl can't generate the operator for .= in
> package Property anymore (because fallback is '0' in that package), so
> we need to work around that; this patch implements the least intrusive
> workaround possible.
>
> commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
> Author: Rafael Garcia-Suarez <rgs [at] consttype>
> Date: Tue Mar 20 09:17:02 2012 +0100
>
> Lookup overloaded assignment operators when trying to swap the arguments
>
> This is in the case where we search for an overloaded operator when
> passing the AMGf_assign flag (we're executing an assignment operator
> like +=).
>
> At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
> not passed, we first try to look up the overload method corresponding
> to the assignment operator, then the normal one if fallback is
> authorized. However, if this fails, when trying later to find
> overload magic with the arguments swapped (if AMGf_noright is not
> passed), this procedure was not used and we looked up directly the base
> operation from which the assignment operator might be derived.
> As a consequence of what an operator like += might have looked
> autogenerated even when fallback=>0 was passed.
>
> This change only necessitates a minor adjustment in lib/overload.t,
> where an overloaded += method wasn't corresponding semantically to the
> overloaded + method of the same class, which can be seen as a
> pathological case.

One more reason that I think we should revert this change.

-doy

rgs at consttype

Jul 14, 2012, 6:05 AM

Post #4 of 8 (115 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On 6 July 2012 16:38, Jesse Luehrs <doy [at] tozt> wrote:
> On Fri, Jul 06, 2012 at 01:28:49PM +0100, Nicholas Clark wrote:
>> On Thu, Jul 05, 2012 at 10:46:26PM -0700, Andreas J. Koenig via RT wrote:
>>
>> > f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
>> > 5f9f83be9cdcd54449f7f40db078fe367d780475
>> > We cannot bisect more!
>>
>> For information:
>>
>> $ git log f041cf0f9c6469c41de8b73d5f7b426710c3ff8b^! 5f9f83be9cdcd54449f7f40db078fe367d780475
>> commit 5f9f83be9cdcd54449f7f40db078fe367d780475
>> Author: Rafael Garcia-Suarez <rgs [at] consttype>
>> Date: Tue May 22 17:23:20 2012 +0200
>>
>> Fix mktables bug due to the previous overload fix
>>
>> Due to the previous patch, perl can't generate the operator for .= in
>> package Property anymore (because fallback is '0' in that package), so
>> we need to work around that; this patch implements the least intrusive
>> workaround possible.
>>
>> commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
>> Author: Rafael Garcia-Suarez <rgs [at] consttype>
>> Date: Tue Mar 20 09:17:02 2012 +0100
>>
>> Lookup overloaded assignment operators when trying to swap the arguments
>>
>> This is in the case where we search for an overloaded operator when
>> passing the AMGf_assign flag (we're executing an assignment operator
>> like +=).
>>
>> At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
>> not passed, we first try to look up the overload method corresponding
>> to the assignment operator, then the normal one if fallback is
>> authorized. However, if this fails, when trying later to find
>> overload magic with the arguments swapped (if AMGf_noright is not
>> passed), this procedure was not used and we looked up directly the base
>> operation from which the assignment operator might be derived.
>> As a consequence of what an operator like += might have looked
>> autogenerated even when fallback=>0 was passed.
>>
>> This change only necessitates a minor adjustment in lib/overload.t,
>> where an overloaded += method wasn't corresponding semantically to the
>> overloaded + method of the same class, which can be seen as a
>> pathological case.
>
> One more reason that I think we should revert this change.
>

Do you think the fix is incorrect ? It actually cleans up a part of
the overload code that was not symmetrical and sanitizes the semantics
of overload generation.

andreas.koenig.7os6VVqR at franz

Aug 9, 2012, 12:01 AM

Post #5 of 8 (96 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

Another data point: MAGGIEXYZ/PDL-Stats-0.6.2.tar.gz also got broken with
this commit (https://rt.perl.org/rt3//Public/Bug/Display.html?id=114008)

--
andreas

rgs at consttype

Aug 27, 2012, 11:49 PM

Post #6 of 8 (88 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On 17 August 2012 23:27, Father Chrysostomos via RT
<perlbug-followup [at] perl> wrote:
> On Sat Jul 14 06:06:14 2012, rgs [at] consttype wrote:
>> Do you think the fix is incorrect ?
>
> Yes.
>
>> It actually cleans up a part of
>> the overload code that was not symmetrical and sanitizes the semantics
>> of overload generation.
>
> But up until now, overloaded assignment operators have not been
> symmetrical. Making them so will break any code that implements them.
>
> From a user�s point of view, I wouldn�t expect to have to deal with $x
> += $my_overloaded_object inside a += override. Inside a + override
> makes sense. If fallback is 0, then $x += $pluseq_overloaded should die.

That's what my patch had fixed, IIRC. Previously, even with
fallback=>0 the overloaded operator += could have been generated from
+.

doy at tozt

Aug 28, 2012, 1:10 AM

Post #7 of 8 (89 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On Tue, Aug 28, 2012 at 08:49:15AM +0200, Rafael Garcia-Suarez wrote:
> On 17 August 2012 23:27, Father Chrysostomos via RT
> <perlbug-followup [at] perl> wrote:
> > On Sat Jul 14 06:06:14 2012, rgs [at] consttype wrote:
> >> Do you think the fix is incorrect ?
> >
> > Yes.
> >
> >> It actually cleans up a part of
> >> the overload code that was not symmetrical and sanitizes the semantics
> >> of overload generation.
> >
> > But up until now, overloaded assignment operators have not been
> > symmetrical. Making them so will break any code that implements them.
> >
> > From a user’s point of view, I wouldn’t expect to have to deal with $x
> > += $my_overloaded_object inside a += override. Inside a + override
> > makes sense. If fallback is 0, then $x += $pluseq_overloaded should die.
>
> That's what my patch had fixed, IIRC. Previously, even with
> fallback=>0 the overloaded operator += could have been generated from
> +.

Right, but in fixing that, you broke something else (+= should not be
checking overloadedness of the right hand side).

-doy

rgs at consttype

Aug 28, 2012, 5:33 AM

Post #8 of 8 (89 views)
Permalink

Re: [perl #114008] Bleadperl around v5.16.0-150-g5f9f83b breaks LESPEA/Project-Euler-0.20.tar.gz [In reply to]

On 28 August 2012 10:10, Jesse Luehrs <doy [at] tozt> wrote:
> On Tue, Aug 28, 2012 at 08:49:15AM +0200, Rafael Garcia-Suarez wrote:
>> On 17 August 2012 23:27, Father Chrysostomos via RT
>> <perlbug-followup [at] perl> wrote:
>> > On Sat Jul 14 06:06:14 2012, rgs [at] consttype wrote:
>> >> Do you think the fix is incorrect ?
>> >
>> > Yes.
>> >
>> >> It actually cleans up a part of
>> >> the overload code that was not symmetrical and sanitizes the semantics
>> >> of overload generation.
>> >
>> > But up until now, overloaded assignment operators have not been
>> > symmetrical. Making them so will break any code that implements them.
>> >
>> > From a user�s point of view, I wouldn�t expect to have to deal with $x
>> > += $my_overloaded_object inside a += override. Inside a + override
>> > makes sense. If fallback is 0, then $x += $pluseq_overloaded should die.
>>
>> That's what my patch had fixed, IIRC. Previously, even with
>> fallback=>0 the overloaded operator += could have been generated from
>> +.
>
> Right, but in fixing that, you broke something else (+= should not be
> checking overloadedness of the right hand side).

This is right (while + needs to check overloadedness of both sides)

I'm a lot behind in my mail reading, do you know if we have already a
neat self-contained test case that I could use if I want to try to fix
my fix ?

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads