Bleadperl v5.27.6-206-g16ada235c3 breaks JGAMBLE/Algorithm-QuineMcCluskey-0.16.tar.gz

[p5pRT]

Migrated from rt.perl.org#132671 (status was 'open')

Searchable as RT132671$

[p5pRT]

From @andk

bisect

---

commit 16ada23
Author​: Zefram <zefram@​fysh.org>
Date​: Tue Dec 12 09​:47​:41 2017 +0000

  fix GvSV refcounting in sort

diagnostics

---

http://www.cpantesters.org/cpan/report/44ada6c6-e8f1-11e7-a668-697bf7a4fdfd

andreas

[p5pRT]

From @jkeenan

3 test files are failing, 2 with SEGV and 1 with 'panic​: attempt to copy freed scalar'. Please see attached.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

[Algorithm-QuineMcCluskey-0.16] 578 $ /home/jkeenan/testing/threaded_blead/bin/perl -I/home/jkeenan/testing/threaded_blead/lib -Iblib/lib -d t/13-solvesimple.t

Loading DB routines from perl5db.pl version 1.53
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

1..1
Test2::API::CODE(0x3726710)(/home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/Test2/API.pm:41):
41: INIT { eval 'END { test2_set_is_end() }; 1' or die $@ }
DB<1> n
Test2::API::CODE(0x3726710)((eval 217)[/home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/Test2/API.pm:41]:1):
1: END { test2_set_is_end() }; 1
DB<1>
Test::Builder::CODE(0x3aba3a0)(/home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/Test/Builder.pm:99):
99: Test2::API::test2_load() unless Test2::API::test2_in_preload();
DB<1>
main::(t/13-solvesimple.t:11): my($q, $eqn, @expected);
DB<1>
main::(t/13-solvesimple.t:13): $q = Algorithm::QuineMcCluskey->new(
main::(t/13-solvesimple.t:14): title => "Example 3.16 from Introduction to Logic Design, by Sajjan G. Shiva, page 126.",
main::(t/13-solvesimple.t:15): width => 4,
main::(t/13-solvesimple.t:16): minterms => [ 0, 2, 5 .. 8, 10, 12 .. 15 ],
main::(t/13-solvesimple.t:17): );
DB<1>
main::(t/13-solvesimple.t:22): @expected = (
main::(t/13-solvesimple.t:23): q/(AD') + (BD) + (B'D') + (CD')/,
main::(t/13-solvesimple.t:24): q/(AD') + (BC) + (BD) + (B'D')/,
main::(t/13-solvesimple.t:25): q/(AB) + (BC) + (BD) + (B'D')/,
main::(t/13-solvesimple.t:26): q/(AB) + (BD) + (B'D') + (CD')/
main::(t/13-solvesimple.t:27): );
DB<1>
main::(t/13-solvesimple.t:29): $eqn = $q->solve;
DB<1>
Signal SEGV at blib/lib/Algorithm/QuineMcCluskey.pm line 759.
Algorithm::QuineMcCluskey::recurse_solve(Algorithm::QuineMcCluskey=HASH(0x3d22558), HASH(0x34a13b0), 0) called at blib/lib/Algorithm/QuineMcCluskey.pm line 568
Algorithm::QuineMcCluskey::generate_covers(Algorithm::QuineMcCluskey=HASH(0x3d22558)) called at (eval 208)[/home/jkeenan/testing/threaded_blead/lib/perl5/site_perl/5.27.8/Eval/Closure.pm:149] line 13
Algorithm::QuineMcCluskey::get_covers(Algorithm::QuineMcCluskey=HASH(0x3d22558)) called at blib/lib/Algorithm/QuineMcCluskey.pm line 651
Algorithm::QuineMcCluskey::solve(Algorithm::QuineMcCluskey=HASH(0x3d22558)) called at t/13-solvesimple.t line 29
Aborted (core dumped)
[Algorithm-QuineMcCluskey-0.16] 579 $ /home/jkeenan/testing/threaded_blead/bin/perl -I/home/jkeenan/testing/threaded_blead/lib -Iblib/lib -d t/24-solve.t

Loading DB routines from perl5db.pl version 1.53
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

1..3
Test2::API::CODE(0x3579f20)(/home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/Test2/API.pm:41):
41: INIT { eval 'END { test2_set_is_end() }; 1' or die $@ }
DB<1> c
Signal SEGV at blib/lib/Algorithm/QuineMcCluskey.pm line 759.
Algorithm::QuineMcCluskey::recurse_solve(Algorithm::QuineMcCluskey=HASH(0x3b850b8), HASH(0x32f4650), 0) called at blib/lib/Algorithm/QuineMcCluskey.pm line 568
Algorithm::QuineMcCluskey::generate_covers(Algorithm::QuineMcCluskey=HASH(0x3b850b8)) called at (eval 208)[/home/jkeenan/testing/threaded_blead/lib/perl5/site_perl/5.27.8/Eval/Closure.pm:149] line 13
Algorithm::QuineMcCluskey::get_covers(Algorithm::QuineMcCluskey=HASH(0x3b850b8)) called at blib/lib/Algorithm/QuineMcCluskey.pm line 651
Algorithm::QuineMcCluskey::solve(Algorithm::QuineMcCluskey=HASH(0x3b850b8)) called at t/24-solve.t line 29
Aborted (core dumped)
[Algorithm-QuineMcCluskey-0.16] 580 $ /home/jkeenan/testing/threaded_blead/bin/perl -I/home/jkeenan/testing/threaded_blead/lib -Iblib/lib -d t/27-solve.t

Loading DB routines from perl5db.pl version 1.53
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

1..2
Test2::API::CODE(0x3dac070)(/home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/Test2/API.pm:41):
41: INIT { eval 'END { test2_set_is_end() }; 1' or die $@ }
DB<1> c
ok 1 - Solutions are more than 2**width in cost
panic: attempt to copy freed scalar 43eae08 to 23cb558 at /home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/perl5db.pl line 4251.
at /home/jkeenan/testing/threaded_blead/lib/perl5/5.27.8/perl5db.pl line 4251.
Algorithm::QuineMcCluskey::recurse_solve(Algorithm::QuineMcCluskey=HASH(0x43c3870), HASH(0x43ea388), 0) called at blib/lib/Algorithm/QuineMcCluskey.pm line 568
Algorithm::QuineMcCluskey::generate_covers(Algorithm::QuineMcCluskey=HASH(0x43c3870)) called at (eval 208)[/home/jkeenan/testing/threaded_blead/lib/perl5/site_perl/5.27.8/Eval/Closure.pm:149] line 13
Algorithm::QuineMcCluskey::get_covers(Algorithm::QuineMcCluskey=HASH(0x43c3870)) called at blib/lib/Algorithm/QuineMcCluskey.pm line 651
Algorithm::QuineMcCluskey::solve(Algorithm::QuineMcCluskey=HASH(0x43c3870)) called at t/27-solve.t line 49
Attempt to free unreferenced scalar: SV 0x43eae08, Perl interpreter: 0x1dd8010.
at t/27-solve.t line 0.
# Looks like your test exited with 255 just after 1.
Debugged program terminated. Use q to quit or R to restart,
use o inhibit_exit to avoid stopping after program termination,
h q, h R or h o to get additional info.
DB<1> c
Use 'q' to quit or 'R' to restart. 'h q' for details.
DB<1> q

#####

Summary of my perl5 (revision 5 version 27 subversion 8) configuration:
Commit id: dce3f5c3fd788f1c2e451e3760f05a347c949eff
Platform:
osname=linux
osvers=4.4.0-104-generic
archname=x86_64-linux-thread-multi
uname='linux zareason 4.4.0-104-generic #127-ubuntu smp mon dec 11 12:16:42 utc 2017 x86_64 x86_64 x86_64 gnulinux '
config_args='-des -Dusedevel -Dusethreads -Uversiononly -Dprefix=/home/jkeenan/testing/threaded_blead -Dman1dir=none -Dman3dir=none'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
optimize='-O2'
cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='5.4.1 20160904'
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='cc'
ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/5/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 /lib64 /usr/lib64
libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.23.so
so=so
useshrplib=false
libperl=libperl.a
gnulibc_version='2.23'
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-E'
cccdlflags='-fPIC'
lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
PERL_USE_DEVEL
USE_64_BIT_ALL
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
USE_REENTRANT_API

[p5pRT]

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

[p5pRT]

From zefram@fysh.org

This problem isn't actually with Algorithm-QuineMcCluskey, but with
List-MoreUtils-XS. It's another GvSV refcounting bug in List-MoreUtils-XS
that is being uncovered by having fixed pp_sort. We previously saw a
similar failure in List-MoreUtils-XS's own test suite, [perl #132578].
A new version of List-MoreUtils-XS has been released which doesn't fail
in its own test suite, but still has GvSV refcounting bugs. The one
hitting Algorithm-QuineMcCluskey is with pairwise()​:

$ perl -MDevel​::Peek=Dump -MList​::MoreUtils​::XS=pairwise -lwe 'pairwise { } @​{["0"]}, @​{["0"]}; Dump $a; Dump $b'
SV = UNKNOWN(0xff) (0xfecab0) at 0xfc9128
  REFCNT = 0
  FLAGS = ()
SV = UNKNOWN(0xff) (0xfecb88) at 0xfecac8
  REFCNT = 0
  FLAGS = ()

This bug falls within the scope of [rt.cpan.org #123868] that I opened
in response to #16301 I'll add a comment to it about this
particular problem.

-zefram

[p5pRT]

From @eserte

This happens now with perl 5.26.2 RC1, too.

[p5pRT]

From @iabyn

On Mon, Jan 01, 2018 at 03​:24​:18PM +0000, Zefram wrote​:

This problem isn't actually with Algorithm-QuineMcCluskey, but with
List-MoreUtils-XS. It's another GvSV refcounting bug in List-MoreUtils-XS
that is being uncovered by having fixed pp_sort. We previously saw a
similar failure in List-MoreUtils-XS's own test suite, [perl #132578].
A new version of List-MoreUtils-XS has been released which doesn't fail
in its own test suite, but still has GvSV refcounting bugs. The one
hitting Algorithm-QuineMcCluskey is with pairwise()​:

$ perl -MDevel​::Peek=Dump -MList​::MoreUtils​::XS=pairwise -lwe 'pairwise { } @​{["0"]}, @​{["0"]}; Dump $a; Dump $b'
SV = UNKNOWN(0xff) (0xfecab0) at 0xfc9128
REFCNT = 0
FLAGS = ()
SV = UNKNOWN(0xff) (0xfecb88) at 0xfecac8
REFCNT = 0
FLAGS = ()

This bug falls within the scope of [rt.cpan.org #123868] that I opened
in response to [perl #132578]. I'll add a comment to it about this
particular problem.

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers list.

--
You never really learn to swear until you learn to drive.

[p5pRT]

From @iabyn

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers list.

Now done.

--
Lear​: Dost thou call me fool, boy?
Fool​: All thy other titles thou hast given away; that thou wast born with.

[p5pRT]

From @eserte

Dana Mon, 23 Apr 2018 05​:23​:45 -0700, davem reče​:

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers list.

Now done.

Please can you make sure that affected CPAN modules get a ticket in its own queues when removing something from the blockers list? I did so for this one​: https://rt.cpan.org/Ticket/Display.html?id=125391

[p5pRT]

From @iabyn

On Wed, May 23, 2018 at 10​:39​:26PM -0700, slaven@​rezic.de via RT wrote​:

Dana Mon, 23 Apr 2018 05​:23​:45 -0700, davem reče​:

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers list.

Now done.

Please can you make sure that affected CPAN modules get a ticket in its own queues when removing something from the blockers list? I did so for this one​: https://rt.cpan.org/Ticket/Display.html?id=125391

I fail to see how the act of determining that a particular issue is not a
blocker makes me personally responsible for raising tickets against one or
more CPAN modules which have a dependency on a CPAN module which has bug?

--
In my day, we used to edit the inodes by hand. With magnets.

[p5pRT]

From @eserte

Dana Thu, 24 May 2018 05​:22​:12 -0700, davem reče​:

On Wed, May 23, 2018 at 10​:39​:26PM -0700, slaven@​rezic.de via RT
wrote​:

Dana Mon, 23 Apr 2018 05​:23​:45 -0700, davem reče​:

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers
list.

Now done.

Please can you make sure that affected CPAN modules get a ticket in
its own queues when removing something from the blockers list? I did
so for this one​: https://rt.cpan.org/Ticket/Display.html?id=125391

I fail to see how the act of determining that a particular issue is
not a
blocker makes me personally responsible for raising tickets against
one or
more CPAN modules which have a dependency on a CPAN module which has
bug?

We have a de facto process for dealing with breakages caused by changes in perl. If this breakage is a documented one and unlikely to be reverted, then the tickets go directly to the affected CPAN modules. If it is not, then a BBC ticket is created first, with a link to a blocker ticket. If now this BBC ticket is closed or the blocker link removed, then the information chain about the breakage is effectively broken --- without informing the CPAN authors.

And it does not matter if a CPAN module is directly or only indirectly affected. The author of the indirectly affected module may decide to use an alternative module or implementation.

So yes​: anybody closing a ticket or removing a blocker link should make sure that every interested party is informed.

[p5pRT]

From @craigberry

On Fri, Jun 8, 2018 at 1​:43 AM, slaven@​rezic.de via RT
<perlbug-followup@​perl.org> wrote​:

Dana Thu, 24 May 2018 05​:22​:12 -0700, davem reče​:

On Wed, May 23, 2018 at 10​:39​:26PM -0700, slaven@​rezic.de via RT
wrote​:

Dana Mon, 23 Apr 2018 05​:23​:45 -0700, davem reče​:

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28 blockers
list.

Now done.

Please can you make sure that affected CPAN modules get a ticket in
its own queues when removing something from the blockers list? I did
so for this one​: https://rt.cpan.org/Ticket/Display.html?id=125391

I fail to see how the act of determining that a particular issue is
not a
blocker makes me personally responsible for raising tickets against
one or
more CPAN modules which have a dependency on a CPAN module which has
bug?

We have a de facto process for dealing with breakages caused by changes in perl. If this breakage is a documented one and unlikely to be reverted, then the tickets go directly to the affected CPAN modules. If it is not, then a BBC ticket is created first, with a link to a blocker ticket. If now this BBC ticket is closed or the blocker link removed, then the information chain about the breakage is effectively broken --- without informing the CPAN authors.

And it does not matter if a CPAN module is directly or only indirectly affected. The author of the indirectly affected module may decide to use an alternative module or implementation.

So yes​: anybody closing a ticket or removing a blocker link should make sure that every interested party is informed.

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest. IMO the core
grant recipients have quite enough to do keeping up with the core RT
queue and its security-related equivalent (which has seen a major
uptick in activity in the last couple of years). Making them
responsible for CPAN RT as well is more or less implementing a command
economy ("Thou shalt increase productivity by 100%!") -- more work
with no resources to do it. Of course it would be great if some
volunteer(s) stepped up to provide this service, but there is no
reason this activity should block core releases, which is what the
blocker link is for.

[p5pRT]

From @eserte

Dana Fri, 08 Jun 2018 12​:21​:27 -0700, craig.a.berry@​gmail.com reče​:

On Fri, Jun 8, 2018 at 1​:43 AM, slaven@​rezic.de via RT
<perlbug-followup@​perl.org> wrote​:

Dana Thu, 24 May 2018 05​:22​:12 -0700, davem reče​:

On Wed, May 23, 2018 at 10​:39​:26PM -0700, slaven@​rezic.de via RT
wrote​:

Dana Mon, 23 Apr 2018 05​:23​:45 -0700, davem reče​:

On Fri, Apr 20, 2018 at 12​:00​:02AM +0100, Dave Mitchell wrote​:

(this was followed up with
https://rt.cpan.org/Public/Bug/Display.html?id=123989
)

Since its been confirmed that its bugs in List-MoreUtils-XS,
I propose that this perl ticket is removed from the 5.28
blockers
list.

Now done.

Please can you make sure that affected CPAN modules get a ticket
in
its own queues when removing something from the blockers list? I
did
so for this one​: https://rt.cpan.org/Ticket/Display.html?id=125391

I fail to see how the act of determining that a particular issue is
not a
blocker makes me personally responsible for raising tickets against
one or
more CPAN modules which have a dependency on a CPAN module which has
bug?

We have a de facto process for dealing with breakages caused by
changes in perl. If this breakage is a documented one and unlikely to
be reverted, then the tickets go directly to the affected CPAN
modules. If it is not, then a BBC ticket is created first, with a
link to a blocker ticket. If now this BBC ticket is closed or the
blocker link removed, then the information chain about the breakage
is effectively broken --- without informing the CPAN authors.

And it does not matter if a CPAN module is directly or only
indirectly affected. The author of the indirectly affected module may
decide to use an alternative module or implementation.

So yes​: anybody closing a ticket or removing a blocker link should
make sure that every interested party is informed.

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.

In this case possibly interested parties (i.e. the author of the affected CPAN module) were not informed at all.

IMO the core
grant recipients have quite enough to do keeping up with the core RT
queue and its security-related equivalent (which has seen a major
uptick in activity in the last couple of years). Making them
responsible for CPAN RT as well is more or less implementing a command
economy ("Thou shalt increase productivity by 100%!") -- more work
with no resources to do it. Of course it would be great if some
volunteer(s) stepped up to provide this service, but there is no
reason this activity should block core releases, which is what the
blocker link is for.

A blocker is created for a purpose​: to evaluate and possibly avoid breakage which would be caused by a new perl release. If it was decided that the breakage will happen nevertheless, then I would expect that there's some help for the affected authors to fix their code. But at the very minimum it should be made sure that known breakages are at least communicated to the authors.

[p5pRT]

From @khwilliamson

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at ticket
creation time?

[p5pRT]

From @eserte

Dana Sun, 10 Jun 2018 08​:54​:06 -0700, public@​khwilliamson.com reče​:

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the
affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at
ticket
creation time?

Often bleadperl failures are fixed, without the need to tell the module owners.

[p5pRT]

From @khwilliamson

On 06/10/2018 11​:27 AM, slaven@​rezic.de via RT wrote​:

Dana Sun, 10 Jun 2018 08​:54​:06 -0700, public@​khwilliamson.com reče​:

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the
affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at
ticket
creation time?

Often bleadperl failures are fixed, without the need to tell the module owners.

True,

The argument against this idea is that it may unnecessarily alarm them.

The argument for it is that they are a stakeholder, and should be given
a heads up about things. In cases where the problem is too much
dependence on undocumented/unpromised core behavior, they may well have
some wisdom to contribute.

In any event, the time to notify them is long before the ticket is
removed from the blockers list.

The latest that we should notify them, I believe is when the discussion
in the ticket veers towards the module being part of the problem. That
we're not doing, and it requires some conscious effort to do so, so
can't be relied on.

So I still lean to changing BBC tickets to automatically notify the
module's maintainers. Text could be added to this message to quell
their anxieties.

There could be a short exclude list of authors who we don't notify,
because past experience has shown them to violate Hanlon's law.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132671

[p5pRT]

From @khwilliamson

On 06/10/2018 11​:27 AM, slaven@​rezic.de via RT wrote​:

Dana Sun, 10 Jun 2018 08​:54​:06 -0700, public@​khwilliamson.com reče​:

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the
affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at
ticket
creation time?

Often bleadperl failures are fixed, without the need to tell the module owners.

True,

The argument against this idea is that it may unnecessarily alarm them.

The argument for it is that they are a stakeholder, and should be given
a heads up about things. In cases where the problem is too much
dependence on undocumented/unpromised core behavior, they may well have
some wisdom to contribute.

In any event, the time to notify them is long before the ticket is
removed from the blockers list.

The latest that we should notify them, I believe is when the discussion
in the ticket veers towards the module being part of the problem. That
we're not doing, and it requires some conscious effort to do so, so
can't be relied on.

So I still lean to changing BBC tickets to automatically notify the
module's maintainers. Text could be added to this message to quell
their anxieties.

There could be a short exclude list of authors who we don't notify,
because past experience has shown them to violate Hanlon's law.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132671

[p5pRT]

From @xsawyerx

On 06/10/2018 08​:27 PM, slaven@​rezic.de via RT wrote​:

Dana Sun, 10 Jun 2018 08​:54​:06 -0700, public@​khwilliamson.com reče​:

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the
affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at
ticket
creation time?
Often bleadperl failures are fixed, without the need to tell the module owners.

I tend to inform the author if it's someone I know (even passingly), but
I think you raise a good point about the author needing to at least know
that their module is affected. Doubly so if we think it's an error they
need to fix and we do not intend to undo.

I think Karl's suggestion is the very minimum of communication we can
provide the author to keep them in the loop. If it's eventually resolved
on our end, they wouldn't need to do a thing, but they would at least
know. If we determine they had a bug, they would see it in the
correspondence.

It's a valuable step to add to the process.

[p5pRT]

From @khwilliamson

On 06/30/2018 05​:23 AM, Sawyer X wrote​:

On 06/10/2018 08​:27 PM, slaven@​rezic.de via RT wrote​:

Dana Sun, 10 Jun 2018 08​:54​:06 -0700, public@​khwilliamson.com reče​:

On 06/10/2018 06​:45 AM, slaven@​rezic.de via RT wrote​:

I fail to see how removing the blocker link causes any loss of
information as long as the ticket is left open. Interested parties
can act on it whenever, well, they take an interest.
In this case possibly interested parties (i.e. the author of the
affected CPAN module) were not informed at all.

Shouldn't the module owner automatically be placed in the cc​: at
ticket
creation time?
Often bleadperl failures are fixed, without the need to tell the module owners.

I tend to inform the author if it's someone I know (even passingly), but
I think you raise a good point about the author needing to at least know
that their module is affected. Doubly so if we think it's an error they
need to fix and we do not intend to undo.

I think Karl's suggestion is the very minimum of communication we can
provide the author to keep them in the loop. If it's eventually resolved
on our end, they wouldn't need to do a thing, but they would at least
know. If we determine they had a bug, they would see it in the
correspondence.

It's a valuable step to add to the process.

The message we send needs to be carefully crafted so as to not
unnecessarily alarm the author. Below is an initial draft. Feel free
to edit it and post the results. Maybe we should use a wiki.

This is a heads-up to let you know that XXX is no longer fully working
in the latest development release of Perl. Don't panic. Usually this
is the result of a change creating a new bug in the core, and it will be
duly investigated and fixed without you having to do anything. But as a
listed maintainer of the module, we think you should be kept aware of
the progress of this issue, and so you have automatically been added to
the copy-to list for correspondence about it. You, of course, may have
valuable insights, so feel free to participate in the discussion.

[p5pRT]

From @andk

Better late than never.

commit 16ada23
Author​: Zefram <zefram@​fysh.org>
Date​: Tue Dec 12 09​:47​:41 2017 +0000

  fix GvSV refcounting in sort

This commit is also known as a backport to 5.26​:

commit 6a4c4e8
Author​: Zefram <zefram@​fysh.org>
Date​: Mon Mar 12 08​:27​:48 2018 +0000

  fix GvSV refcounting in sort

Sample fail reports​:

http​://www.cpantesters.org/cpan/report/a5dceaca-a7ee-11e9-96e4-89468076829d
http​://www.cpantesters.org/cpan/report/3e9cb86a-a80a-11e9-8dbb-bc4e8076829d

Have the appropriate amount of fun,
--
andreas
PS​: perl,perl,perl

[p5pRT]

From @andk

On Tue, 16 Jul 2019 13​:53​:07 -0700, "(Andreas J. Koenig) (via RT)" <perlbug-followup@​perl.org> said​:

  > fix GvSV refcounting in sort

It looks like a duplicate of https://rt.perl.org/Public/Bug/Display.html?id=132671

--
andreas

[toddr]

The original issue raised in this ticket was reported via https://rt.cpan.org/Public/Bug/Display.html?id=123989 I don't see any action required at this point for this ticket. If we need to discuss BBC reporting policies, I don't think that discussion belongs here.

I propose closing this ticket.

[jkeenan]

The original issue raised in this ticket was reported via https://rt.cpan.org/Public/Bug/Display.html?id=123989 I don't see any action required at this point for this ticket. If we need to discuss BBC reporting policies, I don't think that discussion belongs here.

Agreed.

Update: The maintainer resolved the ticket filed upstream on RT. So we're good.

I propose closing this ticket.

Closing.

Thank you very much.
Jim Keenan