Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Jan 1, 2018 · 27 comments
Closed
Labels
BBC
Milestone

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Jan 1, 2018

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

Searchable as RT132671$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 1, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jan 1, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jan 1, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jan 1, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 1, 2018

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
Copy link
Author

@p5pRT p5pRT commented Mar 26, 2018

From @eserte

This happens now with perl 5.26.2 RC1, too.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 19, 2018

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
Copy link
Author

@p5pRT p5pRT commented Apr 23, 2018

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
Copy link
Author

@p5pRT p5pRT commented May 24, 2018

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
Copy link
Author

@p5pRT p5pRT commented May 24, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jun 8, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jun 8, 2018

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.

1 similar comment
@p5pRT

This comment has been minimized.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jun 10, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jun 10, 2018

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?

1 similar comment
@p5pRT

This comment has been minimized.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jun 10, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jun 10, 2018

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

1 similar comment
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jun 10, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jul 1, 2018

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.

1 similar comment
@p5pRT

This comment has been minimized.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jul 1, 2018

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.

1 similar comment
@p5pRT

This comment has been minimized.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jul 16, 2019

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
Copy link
Author

@p5pRT p5pRT commented Jul 17, 2019

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 toddr added this to the 5.32.0 milestone Oct 25, 2019
@toddr toddr removed the 5.32.0 label Oct 25, 2019
@toddr toddr added the BBC label Feb 17, 2020
@toddr
Copy link
Member

@toddr toddr commented Feb 17, 2020

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.

@toddr toddr added the Closable? label Feb 17, 2020
@toddr toddr closed this as completed Feb 17, 2020
@toddr toddr removed the Closable? label Feb 17, 2020
@jkeenan
Copy link
Contributor

@jkeenan jkeenan commented Feb 17, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BBC
Projects
None yet
Development

No branches or pull requests

3 participants