| Subject: | Pad corruption under threaded 5.18 |
Pad corruption under threaded 5.18.1
The following snippet shows a bad interaction between
Devel::CallParser and the padrange optimisation:
use Devel::CallParser;
sub string {
my ($i, $s, $t, $u);
my $utf16;
my $is_utf8;
use Devel::Peek;
Dump $utf16;
Dump $is_utf8;
}
string();
(Snippet based on JSON::PP.) The output I get is
SV = NULL(0x0) at 0x7fbdd98eaa48
REFCNT = 1
FLAGS = (PADMY)
SV = NULL(0x0) at 0x7fbdd991d048
REFCNT = 1
FLAGS = (PADSTALE,PADMY)
showing that the $is_utf8 variable is still stale.
Perl commit 7601007 fixes this. The padrange optimisation assumed
that the pad offsets for $u and $utf16 were contiguous.
Devel::CallParser, in creating an rv2cv op, (which gets a gvop kid in
ck_rvconst, which is a padop under threads) extends the pad. Named
pad entries are always added at the end. So there is a hole in
between $u and $utf16.
You might want to consider working around this by using av_fill() on
the pad to shrink it back to its former size when declining to handle
the keyword.
I don’t know whether that will cause other problems. I don’t *think*
so. This workaround will only be necessary for 5.18.0 (or whichever
dev release introduced padrange) to 5.19.3.