Strange behavior of shared array #8039

p5pRT · 2005-07-27T03:09:18Z

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

Searchable as RT36664$

p5pRT · 2005-07-27T03:09:21Z

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 · 2012-05-25T02:26:09Z

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 · 2012-05-25T02:26:10Z

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

p5pRT · 2012-05-25T02:26:10Z

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

p5pRT · 2012-05-25T03:43:44Z

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 · 2012-05-25T03:43:45Z

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 · 2012-05-25T05:24:47Z

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...

fd69380 is the first bad commit
commit fd69380
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 · 2012-05-25T05:24:48Z

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...

fd69380 is the first bad commit
commit fd69380
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 · 2012-05-25T22:15:19Z

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 · 2012-05-25T23:03:30Z

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 · 2012-05-25T23:03:31Z

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

p5pRT · 2012-05-26T07:18:14Z

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 · 2016-07-08T02:41:05Z

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 4bac9ae
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 · 2016-07-08T02:42:45Z

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 4bac9ae
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 · 2016-10-21T16:45:20Z

From @dcollinsn

Tests added in 5422beb, closing.

--
Respectfully,
Dan Collins

p5pRT · 2016-10-21T16:45:20Z

From [Unknown Contact. See original ticket]

Tests added in 5422beb, closing.

--
Respectfully,
Dan Collins

p5pRT · 2016-10-21T16:46:12Z

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

p5pRT closed this as completed Oct 21, 2016

p5pRT added Severity Low distro-All hasTest type-core type-tie labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Strange behavior of shared array #8039

Strange behavior of shared array #8039

p5pRT commented Jul 27, 2005

p5pRT commented Jul 27, 2005

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 26, 2012

p5pRT commented Jul 8, 2016

p5pRT commented Jul 8, 2016

p5pRT commented Oct 21, 2016

p5pRT commented Oct 21, 2016

p5pRT commented Oct 21, 2016

Strange behavior of shared array #8039

Strange behavior of shared array #8039

Comments

p5pRT commented Jul 27, 2005

p5pRT commented Jul 27, 2005

From t-ikegami@aist.go.jp

p5pRT commented May 25, 2012

From @Hugmeir

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

p5pRT commented May 25, 2012

From @cpansprout

p5pRT commented May 25, 2012

From [Unknown Contact. See original ticket]

p5pRT commented May 25, 2012

From @cpansprout

p5pRT commented May 25, 2012

From [Unknown Contact. See original ticket]

p5pRT commented May 25, 2012

From t-ikegami@aist.go.jp

p5pRT commented May 25, 2012

From @Hugmeir

p5pRT commented May 25, 2012

p5pRT commented May 26, 2012

From @iabyn

p5pRT commented Jul 8, 2016

From @dcollinsn

p5pRT commented Jul 8, 2016

From @dcollinsn

p5pRT commented Oct 21, 2016

From @dcollinsn

p5pRT commented Oct 21, 2016

From [Unknown Contact. See original ticket]

p5pRT commented Oct 21, 2016