Strange behavior of shared array

p5pRT commented 19 years ago

Migrated from rt.perl.org#36664 (status was 'resolved')

Searchable as RT36664$

p5pRT commented 19 years ago

From t-ikegami@aist.go.jp

This is a bug report for perl from ikegami@artemis.a01.aist.go.jp\, generated with the help of perlbug 1.35 running under perl v5.8.7.

The following code snippet doesn't work as expected.

#!/usr/bin/perl use threads; use threads::shared;

our @List : shared = (1..5); my $v = 3.5; $v > 0; $List[3] = $v; printf "\@List[(3)] = %s\n"\, @List[(3)]; printf "\$List[3] = %s\n"\, $List[3];

The output looks like: @List[(3)] = 3 $List[3] = 3.5

Without "use threads"\, both @List[(3)] and $List[3] are stringified as "3.5". The "$v > 0" line is somehow essential for the reproduction; when replaced with "$v > 0.5"\, the trouble vanishes.

Flags: category=core severity=low

Site configuration information for perl v5.8.7:

Configured by ikegami at Thu Jun 16 22:21:09 JST 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=linux\, osvers=2.4.18-3\, archname=i686-linux-thread-multi uname='linux artemis.a01.aist.go.jp 2.4.18-3 #1 thu apr 18 07:37:53 edt 2002 i686 unknown ' config_args='-ds -e -Dprefix=/usr -Dusethreads' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm'\, optimize='-O2'\, cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm' ccversion=''\, gccversion='2.96 20000731 (Red Hat Linux 7.3 2.96-110)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.2.5.so\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

@INC for perl v5.8.7: /home/ikegami/lib/perl /usr/lib/perl5/5.8.7/i686-linux-thread-multi /usr/lib/perl5/5.8.7 /usr/lib/perl5/site_perl/5.8.7/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .

Environment for perl v5.8.7: HOME=/home/ikegami LANG=ja_JP.eucJP LANGUAGE (unset) LD_LIBRARY_PATH=/opt/intel_fc_80/lib:/opt/intel/compiler70/ia32/lib LOGDIR (unset) PATH=/home/ikegami/bin:/home/ikegami/util:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/opt/intel_fc_80/bin:/opt/intel/compiler70/ia32/bin:/usr/java/j2re1.4.1/bin:/usr/java/j2sdk1.4.1/bin:/home/ikegami/ninf/linux/bin:. PERL5LIB=/home/ikegami/lib/perl PERL_BADLANG (unset) SHELL=/bin/zsh

p5pRT commented 12 years ago

From @Hugmeir

On Tue Jul 26 20:09:21 2005\, t-ikegami@aist.go.jp wrote:

This is a bug report for perl from ikegami@artemis.a01.aist.go.jp\, generated with the help of perlbug 1.35 running under perl v5.8.7.

----------------------------------------------------------------- The following code snippet doesn't work as expected.

----- #!/usr/bin/perl use threads; use threads::shared;

our @List : shared = (1..5); my $v = 3.5; $v > 0; $List[3] = $v; printf "\@List[(3)] = %s\n"\, @List[(3)]; printf "\$List[3] = %s\n"\, $List[3]; -----

The output looks like: @List[(3)] = 3 $List[3] = 3.5

Without "use threads"\, both @List[(3)] and $List[3] are stringified as "3.5". The "$v > 0" line is somehow essential for the reproduction; when replaced with "$v > 0.5"\, the trouble vanishes. ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl v5.8.7:

Configured by ikegami at Thu Jun 16 22:21:09 JST 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=linux\, osvers=2.4.18-3\, archname=i686-linux-thread-multi uname='linux artemis.a01.aist.go.jp 2.4.18-3 #1 thu apr 18 07:37:53 edt 2002 i686 unknown ' config_args='-ds -e -Dprefix=/usr -Dusethreads' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm'\, optimize='-O2'\, cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm' ccversion=''\, gccversion='2.96 20000731 (Red Hat Linux 7.3 2.96- 110)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.2.5.so\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

--- @INC for perl v5.8.7: /home/ikegami/lib/perl /usr/lib/perl5/5.8.7/i686-linux-thread-multi /usr/lib/perl5/5.8.7 /usr/lib/perl5/site_perl/5.8.7/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .

--- Environment for perl v5.8.7: HOME=/home/ikegami LANG=ja_JP.eucJP LANGUAGE (unset) LD_LIBRARY_PATH=/opt/intel_fc_80/lib:/opt/intel/compiler70/ia32/lib LOGDIR (unset)

PATH=/home/ikegami/bin:/home/ikegami/util:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/opt/intel_fc_80/bin:/opt/intel/compiler70/ia32/bin:/usr/java/j2re1.4.1/bin:/usr/java/j2sdk1.4.1/bin:/home/ikegami/ninf/linux/bin:. PERL5LIB=/home/ikegami/lib/perl PERL_BADLANG (unset) SHELL=/bin/zsh

Fixed in 5.14.2 and 5.16.0\, so I'm marking this as resolved.

(tangentially related\, I'm having issues pinpointing the commit that fixed this. Can someone lend me some bisect.pl-fu?)

p5pRT commented 12 years ago

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

p5pRT commented 12 years ago

@Hugmeir - Status changed from 'open' to 'resolved'

p5pRT commented 12 years ago

From @cpansprout

On Thu May 24 19:26:09 2012\, Hugmeir wrote:

(tangentially related\, I'm having issues pinpointing the commit that fixed this. Can someone lend me some bisect.pl-fu?)

I usually have to tweak my script about five times to get it work\, but the last one I had looked a bit like this:

../perl.git/Porting/bisect.pl -e 'die unless `\Q$^X\E -Ilib ~/script_name 2>&1` =~ /expected_output/'

--

Father Chrysostomos

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

On Thu May 24 19:26:09 2012\, Hugmeir wrote:

(tangentially related\, I'm having issues pinpointing the commit that fixed this. Can someone lend me some bisect.pl-fu?)

I usually have to tweak my script about five times to get it work\, but the last one I had looked a bit like this:

../perl.git/Porting/bisect.pl -e 'die unless `\Q$^X\E -Ilib ~/script_name 2>&1` =~ /expected_output/'

--

Father Chrysostomos

p5pRT commented 12 years ago

From @cpansprout

On Thu May 24 20:43:44 2012\, sprout wrote:

On Thu May 24 19:26:09 2012\, Hugmeir wrote:

(tangentially related\, I'm having issues pinpointing the commit that fixed this. Can someone lend me some bisect.pl-fu?)

I usually have to tweak my script about five times to get it work\, but the last one I had looked a bit like this:

../perl.git/Porting/bisect.pl -e 'die unless `\Q$^X\E -Ilib ~/script_name 2>&1` =~ /expected_output/'

Well\, it took me three tries this time (with ‘warn’ just so I could see what I was getting when it failed at first):

$ ../perl.git/Porting/bisect.pl -Duseithreads -e 'die unless warn ($_=`\Q$^X\E -Ilib ~/foo 2>&1`)\, /3\.5/' --start=v5.12.0 --end=v5.14.0

...lots of output...

fd69380d5d5b95ef16e2521cf4251b34ee0ce151 is the first bad commit commit fd69380d5d5b95ef16e2521cf4251b34ee0ce151 Author: David Mitchell \davem@iabyn\.com Date: Tue Mar 23 12:11:43 2010 +0000

Fix assorted bugs related to magic (such as pos) not "sticking" to magical array and hash elements; e.g. the following looped infinitely:
$h{tainted_element} =~ /..../g
There are two side-effects of this fix. First\, MGf_GSKIP has been extended to work on tied array elements as well as hash elements. This is the mechanism that skips all but the first tied element magic gets until after the next set. Second\, rvalue hash/array element access where the element has get magic\, now directly returns the element rather than a mortal copy.
The root cause of the bug was code similar to the following in pp_alem\, pp_aelemfast\, pp_helem and pp_rv2av:
if (!lval && SvGMAGICAL(sv)) /* see note in pp_helem() */ sv = sv_mortalcopy(sv);
According to the note\, this was added in 1998 to make this work:
local $tied{foo} = $tied{foo}
Since it returns a copy rather than the element\, this make //g fail. My first attempt\, a few years ago\, to fix this\, took the approach that the LHS of the bind should be made an lvalue in the presence of //g\, since it now modifies its LHS; i.e.
expr =~ // expr is rvalue expr =~ s/// expr is lvalue expr =~ //g expr was rvalue\, I proposed to change it to lvalue
Unfortunately this fix broke too much stuff (stuff that was arguably already broken\, but it upset people). For example\, f() ~= s//// correctly gives the error
Can't modify non-lvalue subroutine call
My fix extended f() =~ //g to give the same error. Which is reasonable\, because the g isn't doing what you want. But plenty of people had code that only needed to match once and the g had just been cargo-culted. So it broke their working code. So lets not do this.
My new approach has been to remove the sv_mortalcopy(). It turns out that this is no longer needed to fix the local $tied{foo} issue. Presumably that went away as a side-effect of my container/value magic localisation rationalisation of a few years ago\, although I haven't analysed it - just noted that the tests still pass (!). However\, an issue with removing it is that mg_get() no longer gets called. So a plain
$tied_hash{elem};
in void context no longer calls FETCH(). Which broke some tests and might break some code. Also\, there's an issue with the delayed calling of magic in @+[n] and %+{foo}; by the time the get magic is called\, the original pattern may have gone out of scope.
The solution is to simply replace the original
sv = sv_mortalcopy(sv);
with
mg_get(sv);
This then caused problems with tied array FETCH() getting called too much. I fixed this by extending the MGf_GSKIP mechanism to tied arrays as well as hashes. I don't understand why tied arrays have always been treated differently than tied hashes\, but unifying them didn't seem to break anything (except for a Storable test\, whose comment indicated that the test's author thought FETCH() was being called to often anyway).

:040000 040000 8f820a0e8eced662a2bd03529289ad78ed575ec9 601da445e79dddbca66613d21ec8911694e25f99 M dist :100644 100644 137026d8d0ec9abdcd06d71d3791fd767c5df98c bf8bd53a747e3f5097b7b47ce97219489ad1acc0 M mg.c :100644 100644 fcac411113120ac30e9e9bcedafdfaeaf04fafd7 33628546c9b8d4675105dd67b50963d89f71eec8 M mg.h :100644 100644 3371e889ea8b1c8c75c4f0deb03ee0741304f2b4 8f8af53230ef05db660644c975ccf2edb7685098 M pp_hot.c :040000 040000 e5916e4ddc8b08edb65e329bb29937a5da8cbcee 627307eb7f22223c035a58b56c8fd57901d7fb48 M t bisect run success That took 2034 seconds

--

Father Chrysostomos

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

On Thu May 24 20:43:44 2012\, sprout wrote:

On Thu May 24 19:26:09 2012\, Hugmeir wrote:

(tangentially related\, I'm having issues pinpointing the commit that fixed this. Can someone lend me some bisect.pl-fu?)

I usually have to tweak my script about five times to get it work\, but the last one I had looked a bit like this:

../perl.git/Porting/bisect.pl -e 'die unless `\Q$^X\E -Ilib ~/script_name 2>&1` =~ /expected_output/'

Well\, it took me three tries this time (with ‘warn’ just so I could see what I was getting when it failed at first):

$ ../perl.git/Porting/bisect.pl -Duseithreads -e 'die unless warn ($_=`\Q$^X\E -Ilib ~/foo 2>&1`)\, /3\.5/' --start=v5.12.0 --end=v5.14.0

...lots of output...

fd69380d5d5b95ef16e2521cf4251b34ee0ce151 is the first bad commit commit fd69380d5d5b95ef16e2521cf4251b34ee0ce151 Author: David Mitchell \davem@iabyn\.com Date: Tue Mar 23 12:11:43 2010 +0000

Fix assorted bugs related to magic (such as pos) not "sticking" to magical array and hash elements; e.g. the following looped infinitely:
$h{tainted_element} =~ /..../g
There are two side-effects of this fix. First\, MGf_GSKIP has been extended to work on tied array elements as well as hash elements. This is the mechanism that skips all but the first tied element magic gets until after the next set. Second\, rvalue hash/array element access where the element has get magic\, now directly returns the element rather than a mortal copy.
The root cause of the bug was code similar to the following in pp_alem\, pp_aelemfast\, pp_helem and pp_rv2av:
if (!lval && SvGMAGICAL(sv)) /* see note in pp_helem() */ sv = sv_mortalcopy(sv);
According to the note\, this was added in 1998 to make this work:
local $tied{foo} = $tied{foo}
Since it returns a copy rather than the element\, this make //g fail. My first attempt\, a few years ago\, to fix this\, took the approach that the LHS of the bind should be made an lvalue in the presence of //g\, since it now modifies its LHS; i.e.
expr =~ // expr is rvalue expr =~ s/// expr is lvalue expr =~ //g expr was rvalue\, I proposed to change it to lvalue
Unfortunately this fix broke too much stuff (stuff that was arguably already broken\, but it upset people). For example\, f() ~= s//// correctly gives the error
Can't modify non-lvalue subroutine call
My fix extended f() =~ //g to give the same error. Which is reasonable\, because the g isn't doing what you want. But plenty of people had code that only needed to match once and the g had just been cargo-culted. So it broke their working code. So lets not do this.
My new approach has been to remove the sv_mortalcopy(). It turns out that this is no longer needed to fix the local $tied{foo} issue. Presumably that went away as a side-effect of my container/value magic localisation rationalisation of a few years ago\, although I haven't analysed it - just noted that the tests still pass (!). However\, an issue with removing it is that mg_get() no longer gets called. So a plain
$tied_hash{elem};
in void context no longer calls FETCH(). Which broke some tests and might break some code. Also\, there's an issue with the delayed calling of magic in @+[n] and %+{foo}; by the time the get magic is called\, the original pattern may have gone out of scope.
The solution is to simply replace the original
sv = sv_mortalcopy(sv);
with
mg_get(sv);
This then caused problems with tied array FETCH() getting called too much. I fixed this by extending the MGf_GSKIP mechanism to tied arrays as well as hashes. I don't understand why tied arrays have always been treated differently than tied hashes\, but unifying them didn't seem to break anything (except for a Storable test\, whose comment indicated that the test's author thought FETCH() was being called to often anyway).

:040000 040000 8f820a0e8eced662a2bd03529289ad78ed575ec9 601da445e79dddbca66613d21ec8911694e25f99 M dist :100644 100644 137026d8d0ec9abdcd06d71d3791fd767c5df98c bf8bd53a747e3f5097b7b47ce97219489ad1acc0 M mg.c :100644 100644 fcac411113120ac30e9e9bcedafdfaeaf04fafd7 33628546c9b8d4675105dd67b50963d89f71eec8 M mg.h :100644 100644 3371e889ea8b1c8c75c4f0deb03ee0741304f2b4 8f8af53230ef05db660644c975ccf2edb7685098 M pp_hot.c :040000 040000 e5916e4ddc8b08edb65e329bb29937a5da8cbcee 627307eb7f22223c035a58b56c8fd57901d7fb48 M t bisect run success That took 2034 seconds

--

Father Chrysostomos

p5pRT commented 12 years ago

From t-ikegami@aist.go.jp

Dear Brian\,

Mmm\, It seems that the behavior is changed\, but not resolved yet. I observe now

@List[(3)] = 3 $List[3] = 3

\, which are not the expected results of

@List[(3)] = 3.5 $List[3] = 3.5

I've tested on perl 5.14.2 (comes with Ubuntu 12.04) and perl 5.16.0 (just compiled).

BTW\, I totally forget about how I have encountered with this symptom.

regards\, IKEGAMI\, Tsutomu AIST t-ikegami@aist.go.jp

From: "Brian Fraser via RT" \perlbug\-followup@perl\.org Subject: [perl #36664] [RESOLVED] Strange behavior of shared array Date: Thu\, 24 May 2012 19:26:10 -0700

According to our records\, your request regarding "Strange behavior of shared array" has been resolved.

If you have any further questions or concerns\, please respond to this message.

For other topics\, please create a new ticket.

\<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=36664 >

p5pRT commented 12 years ago

From @Hugmeir

On Fri May 25 15:15:19 2012\, t-ikegami@aist.go.jp wrote:

Dear Brian\,

Mmm\, It seems that the behavior is changed\, but not resolved yet. I observe now

@List[(3)] = 3 $List[3] = 3

\, which are not the expected results of

@List[(3)] = 3.5 $List[3] = 3.5

Whoops\, you are absolutely right; My mistake. Reopening.

For some reason the shared SV doesn't keep the NOK flag\, so it's incorrectly picking the IV slot. For the record\, what Dave M's commit did was make the behavior consistent\, but not correct it.

--hugmeir

p5pRT commented 12 years ago

@Hugmeir - Status changed from 'resolved' to 'open'

p5pRT commented 12 years ago

From @iabyn

On Fri\, May 25\, 2012 at 04:03:31PM -0700\, Brian Fraser via RT wrote:

On Fri May 25 15:15:19 2012\, t-ikegami@aist.go.jp wrote:

Dear Brian\,

Mmm\, It seems that the behavior is changed\, but not resolved yet. I observe now

@List[(3)] = 3 $List[3] = 3

\, which are not the expected results of

@List[(3)] = 3.5 $List[3] = 3.5

Whoops\, you are absolutely right; My mistake. Reopening.

For some reason the shared SV doesn't keep the NOK flag\, so it's incorrectly picking the IV slot. For the record\, what Dave M's commit did was make the behavior consistent\, but not correct it.

Note that this isn't specifically an issue with threads::shared\, but a general issue with tieing (which is how threads::shared is implemented); this code produces the same bad result:

use Tie::Array; tie our @List\, 'Tie::StdArray'; @List = (1..5); my $v = 3.5; $v > 0; $List[3] = $v; printf "\@List[(3)] = %s\n"\, @List[(3)]; printf "\$List[3] = %s\n"\, $List[3];

-- "Foul and greedy Dwarf - you have eaten the last candle." -- "Hordes of the Things"\, BBC Radio.

p5pRT commented 8 years ago

From @dcollinsn

Seems to be fixed.

NY = 3\, 3.5\, NN = 3\, 3\, YY = 3.5\, 3.5.

+base | +-ld | | +-thread-multi | | | +-thread-multi-ld | | | | +-debug | | | | | +-ld-debug | | | | | | +-thread-multi-debug | | | | | | | +-thread-multi-ld-debug +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.003_07 | na | na | - | - | na | na | - | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.004_01 | na | na | - | - | na | na | - | - | |5.004_02 | na | na | - | - | na | na | - | - | |5.004_03 | na | na | - | - | na | na | - | - | |5.004_04 | na | na | - | - | na | na | - | - | |5.004_05 | na | na | - | - | na | na | - | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.6.0 | na | - | nok | - | na | - | nok | - | |5.6.1 | na | - | nok | - | na | - | nok | - | |5.6.2 | na | - | nok | - | na | - | nok | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.8.0 | na | - | NY | - | na | - | NY | - | |5.8.1 | na | - | NY | - | na | - | NY | - | |5.8.2 | na | - | NY | - | na | - | NY | - | |5.8.3 | na | - | NY | - | na | - | NY | - | |5.8.4 | na | - | NY | - | na | - | NY | - | |5.8.5 | na | - | NY | - | na | - | NY | - | |5.8.6 | na | - | NY | - | na | - | NY | - | |5.8.7 | na | na | - | - | na | na | - | - | |5.8.8 | na | - | NY | - | na | - | NY | - | |5.8.9 | na | - | NY | - | na | - | NY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.10.0 | na | - | NY | - | na | - | NY | - | |5.10.1 | na | - | NY | - | na | - | NY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.11.0 | na | - | NY | - | na | - | NY | - | |5.11.1 | na | - | NY | - | na | - | NY | - | |5.11.2 | na | - | NY | - | na | - | NY | - | |5.11.3 | na | - | NY | - | na | - | NY | - | |5.11.4 | na | - | NY | - | na | - | NY | - | |5.11.5 | na | - | NY | - | na | - | NY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.12.0 | na | - | NY | - | na | - | NY | - | |5.12.1 | na | - | NY | - | na | - | NY | - | |5.12.2 | na | - | NY | - | na | - | NY | - | |5.12.3 | na | - | NY | - | na | - | NY | - | |5.12.4 | na | - | NY | - | na | - | NY | - | |5.12.5 | na | - | NY | - | na | - | NY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.13.0 | na | - | NN | - | na | - | NN | - | |5.13.1 | na | - | NN | - | na | - | NN | - | |5.13.2 | na | - | NN | - | na | - | NN | - | |5.13.3 | na | - | NN | - | na | - | NN | - | |5.13.4 | na | - | NN | - | na | - | NN | - | |5.13.5 | na | - | NN | - | na | - | NN | - | |5.13.6 | na | - | NN | - | na | - | NN | - | |5.13.7 | na | - | NN | - | na | - | NN | - | |5.13.8 | na | - | NN | - | na | - | NN | - | |5.13.9 | na | - | NN | - | na | - | NN | - | |5.13.10 | na | - | NN | - | na | - | NN | - | |5.13.11 | na | - | NN | - | na | - | NN | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.14.0 | na | - | NN | - | na | - | NN | - | |5.14.1 | na | - | NN | - | na | - | NN | - | |5.14.2-RC1 | na | - | NN | - | na | - | NN | - | |5.14.2 | na | - | NN | - | na | - | NN | - | |5.14.3 | na | - | NN | - | na | - | NN | - | |5.14.4-RC1 | na | - | NN | - | na | - | NN | - | |5.14.4-RC2 | na | - | NN | - | na | - | NN | - | |5.14.4 | na | - | NN | - | na | - | NN | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.15.0 | na | - | NN | - | na | - | NN | - | |5.15.1 | na | - | NN | - | na | - | NN | - | |5.15.2 | na | - | NN | - | na | - | NN | - | |5.15.3 | na | - | NN | - | na | - | NN | - | |5.15.4 | na | - | NN | - | na | - | NN | - | |5.15.5 | na | - | NN | - | na | - | NN | - | |5.15.6 | na | - | NN | - | na | - | NN | - | |5.15.7 | na | - | NN | - | na | - | NN | - | |5.15.8 | na | - | NN | - | na | - | NN | - | |5.15.9 | na | - | NN | - | na | - | NN | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.16.0 | na | - | NN | - | na | - | NN | - | |5.16.1 | na | - | NN | - | na | - | NN | - | |5.16.2 | na | - | NN | - | na | - | NN | - | |5.16.3 | na | - | NN | - | na | - | NN | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.17.0 | na | - | NN | - | na | - | NN | - | |5.17.1 | na | - | NN | - | na | - | NN | - | |5.17.2 | na | - | YY | - | na | - | YY | - | |5.17.3 | na | - | YY | - | na | - | YY | - | |5.17.4 | na | - | YY | - | na | - | YY | - | |5.17.5 | na | - | YY | - | na | - | YY | - | |5.17.6 | na | - | YY | - | na | - | YY | - | |5.17.7 | na | - | YY | - | na | - | YY | - | |5.17.8 | na | - | YY | - | na | - | YY | - | |5.17.9 | na | - | YY | - | na | - | YY | - | |5.17.10 | na | - | YY | - | na | - | YY | - | |5.17.11 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.18.0 | na | - | YY | - | na | - | YY | - | |5.18.1 | na | - | YY | - | na | - | YY | - | |5.18.2 | na | - | YY | - | na | - | YY | - | |5.18.3 | na | - | YY | - | na | - | YY | - | |5.18.4 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.19.0 | na | - | YY | - | na | - | YY | - | |5.19.1 | na | - | YY | - | na | - | YY | - | |5.19.2 | na | - | YY | - | na | - | YY | - | |5.19.3 | na | - | YY | - | na | - | YY | - | |5.19.4 | na | - | YY | - | na | - | YY | - | |5.19.5 | na | - | YY | - | na | - | YY | - | |5.19.6 | na | - | YY | - | na | - | YY | - | |5.19.7 | na | - | YY | - | na | - | YY | - | |5.19.8 | na | - | YY | - | na | - | YY | - | |5.19.9 | na | - | YY | - | na | - | YY | - | |5.19.10 | na | - | YY | - | na | - | YY | - | |5.19.11 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.20.0 | na | - | YY | - | na | - | YY | - | |5.20.1-RC1 | na | - | YY | - | na | - | YY | - | |5.20.1-RC2 | na | - | YY | - | na | - | YY | - | |5.20.1 | na | - | YY | - | na | - | YY | - | |5.20.2-RC1 | na | - | YY | - | na | - | YY | - | |5.20.2 | na | - | YY | - | na | - | YY | - | |5.20.3-RC1 | na | - | YY | - | na | - | YY | - | |5.20.3-RC2 | na | - | YY | - | na | - | YY | - | |5.20.3 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.21.0 | na | - | YY | - | na | - | YY | - | |5.21.1 | na | - | YY | - | na | - | YY | - | |5.21.2 | na | - | YY | - | na | - | YY | - | |5.21.3 | na | - | YY | - | na | - | YY | - | |5.21.4 | na | - | YY | - | na | - | YY | - | |5.21.5 | na | - | YY | - | na | - | YY | - | |5.21.6 | na | - | YY | - | na | - | YY | - | |5.21.7 | na | - | YY | - | na | - | YY | - | |5.21.8 | na | - | YY | - | na | - | YY | - | |5.21.9 | na | - | YY | - | na | - | YY | - | |5.21.10 | na | - | YY | - | na | - | YY | - | |5.21.11 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.22.0 | na | - | YY | - | na | - | YY | - | |5.22.1-RC1 | na | - | YY | - | na | - | YY | - | |5.22.1-RC2 | na | - | YY | - | na | - | YY | - | |5.22.1-RC3 | na | - | YY | - | na | - | YY | - | |5.22.1-RC4 | na | - | YY | - | na | - | YY | - | |5.22.1 | na | - | YY | - | na | - | YY | - | |5.22.2-RC1 | na | - | YY | - | na | - | YY | - | |5.22.2 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.23.0 | na | - | YY | - | na | - | YY | - | |5.23.1 | na | - | YY | - | na | - | YY | - | |5.23.2 | na | - | YY | - | na | - | YY | - | |5.23.3 | na | - | YY | - | na | - | YY | - | |5.23.4 | na | - | YY | - | na | - | YY | - | |5.23.5 | na | - | YY | - | na | - | YY | - | |5.23.6 | na | - | YY | - | na | - | YY | - | |5.23.7 | na | - | YY | - | na | - | YY | - | |5.23.8 | na | - | YY | - | na | - | YY | - | |5.23.9 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.24.0-RC1 | na | - | YY | - | na | - | YY | - | |5.24.0-RC2 | na | - | YY | - | na | - | YY | - | |5.24.0-RC3 | na | - | YY | - | na | - | YY | - | |5.24.0-RC4 | na | - | YY | - | na | - | YY | - | |5.24.0-RC5 | na | - | YY | - | na | - | YY | - | |5.24.0 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ |5.25.0 | na | - | YY | - | na | - | YY | - | |5.25.1 | na | - | YY | - | na | - | YY | - | |5.25.2 | na | - | YY | - | na | - | YY | - | +-----------+-----+-----+-----+-----+-----+-----+-----+-----+

Porting/bisect.pl --start v5.17.1 --end v5.17.2 -Dcc='ccache gcc-6' -Dusethreads --expect-fail -- ./perl -Ilib ../36664bis.pl

commit 4bac9ae47b5ad7845a24e26b0e95609805de688a Author: Chip Salzenberg \chip@pobox\.com Date: Fri Jun 22 15:18:18 2012 -0700

Magic flags harmonization.

In restore_magic()\, which is called after any magic processing\, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK\, however\, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV)\, and the inadequate flag shift mechanic broke this in some cases.

This patch removes the shift mechanic for magic flags\, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired\, as the new behavior of empty get functions is to leave the value unchanged. This is a feature\, as now get magic that does not modify its value\, e.g. tainting\, does not have to be special cased.

The changes to cpan/ here are only temporary\, for development only\, to keep blead working until upstream applies them (or something like them).

Thanks to Rik and Father C for review input.

:100644 100644 05516688ceca341ac1f63a7f72f63f38c03c18c6 ce7af44486749f954ef01ca9947a30929cd521ea M av.c :040000 040000 e8cce61b676e554a1a21aec8aada38b7cc26616c 979996a498feb6c0af0468e3b2e2509338a04d97 M cpan :100644 100644 fd6683da2622596820f89d44f5cdcbe845cca4a5 e5098b700200db8ea297c685b56dabd24046125a M doio.c :100644 100644 dd6add2bc5d91feeaeac408126c514ebeb0af1fa 1593d1942ba889cc8d6a5e3545d709ee4ea107cb M doop.c :100644 100644 eb81d9c168b2d74c6df878f943c3e89ba69e8c6d 0f19f7c58ee84793ca0d6f0d7c6c893ea1356e4b M embed.fnc :100644 100644 5dca8e33df73a8ea47b4d3739b21f56deefbae09 a010f2dc02d224219f343159afb4f61e642dc599 M embed.h :040000 040000 0550166d7e2deaa7b3a584c1c41d3903d148420f b3a8da6c82519b0e1b8368a90ae1eba06c0d9039 M ext :100644 100644 e0fdc630e913b217b5a02bc6626f3eabc9c464b8 c1652852622992628a77e66ea1edd1b6271a3a77 M gv.c :100644 100644 1c01152496b21d0d22098b5d8567a1ed04e08b76 dd8003e4c2c1023afae2fbd031b2924b48492d94 M mg.c :100644 100644 661c055ffa8462600b4b0fdac2cdd35ff80b9130 0def4ac35f2693bd07e5a45869cfd63d15aae5d0 M pp.c :100644 100644 826a7729384c80b4d4d06d9b8dfbcca962a6eb28 f2119a77d1e273128ba0598e0a66d0e55ccf7851 M pp_ctl.c :100644 100644 1c0acb92b048ca5ebee12876df4ca4e38f45bbff e04d5ca7ed17719696f050da5e2edd0760079c5f M pp_hot.c :100644 100644 f0a799e238b1aa38338d5069190c7a6ec026a06f 76bd1acbf2390cb68a5b06d26c4c21c030201caa M pp_sys.c :100644 100644 946e9fe76eae1a1e9a39d42604bb2d8e4607b612 db957ac4561e4b639425806f2d38ed0acb64dab0 M proto.h :100644 100644 9caaa4da54d5af559c21bad9dd07bd747eabdcb2 25de4ac77f552d59257923960c04ae9039558247 M sv.c :100644 100644 1eeda1cc5d9568221e1f9fbb1499116b549b9c77 c841c3e246bef6a2e0883c6cde920db8a72c477a M sv.h :040000 040000 348277f03b386dfc5c78b85d03f84da724e64f6a b3a087f58519c7355d399e014750df546351abee M t bisect run success That took 1191 seconds.

Seems believable.

Taking this\, because I've written a test\, which will be included in my big patch o' tests once I finish this audit.

-- Respectfully\, Dan Collins

p5pRT commented 8 years ago

From @dcollinsn

Foiled by RT and a too-long body!

This is fixed by:

Porting/bisect.pl --start v5.17.1 --end v5.17.2 -Dcc='ccache gcc-6' -Dusethreads --expect-fail -- ./perl -Ilib ../36664bis.pl

commit 4bac9ae47b5ad7845a24e26b0e95609805de688a Author: Chip Salzenberg \chip@pobox\.com Date: Fri Jun 22 15:18:18 2012 -0700

Magic flags harmonization.

In restore_magic()\, which is called after any magic processing\, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK\, however\, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV)\, and the inadequate flag shift mechanic broke this in some cases.

This patch removes the shift mechanic for magic flags\, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired\, as the new behavior of empty get functions is to leave the value unchanged. This is a feature\, as now get magic that does not modify its value\, e.g. tainting\, does not have to be special cased.

The changes to cpan/ here are only temporary\, for development only\, to keep blead working until upstream applies them (or something like them).

Thanks to Rik and Father C for review input.

:100644 100644 05516688ceca341ac1f63a7f72f63f38c03c18c6 ce7af44486749f954ef01ca9947a30929cd521ea M av.c :040000 040000 e8cce61b676e554a1a21aec8aada38b7cc26616c 979996a498feb6c0af0468e3b2e2509338a04d97 M cpan :100644 100644 fd6683da2622596820f89d44f5cdcbe845cca4a5 e5098b700200db8ea297c685b56dabd24046125a M doio.c :100644 100644 dd6add2bc5d91feeaeac408126c514ebeb0af1fa 1593d1942ba889cc8d6a5e3545d709ee4ea107cb M doop.c :100644 100644 eb81d9c168b2d74c6df878f943c3e89ba69e8c6d 0f19f7c58ee84793ca0d6f0d7c6c893ea1356e4b M embed.fnc :100644 100644 5dca8e33df73a8ea47b4d3739b21f56deefbae09 a010f2dc02d224219f343159afb4f61e642dc599 M embed.h :040000 040000 0550166d7e2deaa7b3a584c1c41d3903d148420f b3a8da6c82519b0e1b8368a90ae1eba06c0d9039 M ext :100644 100644 e0fdc630e913b217b5a02bc6626f3eabc9c464b8 c1652852622992628a77e66ea1edd1b6271a3a77 M gv.c :100644 100644 1c01152496b21d0d22098b5d8567a1ed04e08b76 dd8003e4c2c1023afae2fbd031b2924b48492d94 M mg.c :100644 100644 661c055ffa8462600b4b0fdac2cdd35ff80b9130 0def4ac35f2693bd07e5a45869cfd63d15aae5d0 M pp.c :100644 100644 826a7729384c80b4d4d06d9b8dfbcca962a6eb28 f2119a77d1e273128ba0598e0a66d0e55ccf7851 M pp_ctl.c :100644 100644 1c0acb92b048ca5ebee12876df4ca4e38f45bbff e04d5ca7ed17719696f050da5e2edd0760079c5f M pp_hot.c :100644 100644 f0a799e238b1aa38338d5069190c7a6ec026a06f 76bd1acbf2390cb68a5b06d26c4c21c030201caa M pp_sys.c :100644 100644 946e9fe76eae1a1e9a39d42604bb2d8e4607b612 db957ac4561e4b639425806f2d38ed0acb64dab0 M proto.h :100644 100644 9caaa4da54d5af559c21bad9dd07bd747eabdcb2 25de4ac77f552d59257923960c04ae9039558247 M sv.c :100644 100644 1eeda1cc5d9568221e1f9fbb1499116b549b9c77 c841c3e246bef6a2e0883c6cde920db8a72c477a M sv.h :040000 040000 348277f03b386dfc5c78b85d03f84da724e64f6a b3a087f58519c7355d399e014750df546351abee M t bisect run success That took 1191 seconds.

Seems believable.

Taking this\, because I've written a test\, which will be included in my big patch o' tests once I finish this audit.

-- Respectfully\, Dan Collins

p5pRT commented 8 years ago

From @dcollinsn

Tests added in 5422beb6e\, closing.

-- Respectfully\, Dan Collins

p5pRT commented 8 years ago

From [Unknown Contact. See original ticket]

Tests added in 5422beb6e\, closing.

-- Respectfully\, Dan Collins

p5pRT commented 8 years ago

@dcollinsn - Status changed from 'open' to 'resolved'

Perl / perl5