On Sun, Aug 21, 2016 at 05:13:51PM +0300, Niko Tyni wrote:
> On Sun, Aug 21, 2016 at 03:13:23PM +0200, gregor herrmann wrote:
> > On Sun, 21 Aug 2016 15:27:34 +0300, Niko Tyni wrote:
>
> > "\x{00c2}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00a1}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00c3}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00a9}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00c2}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00a1}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{fffd}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{fffd}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
> > "\x{00a9}" does not map to ascii at
> > /usr/share/perl/5.22/ExtUtils/MakeMaker.pm line 1187.
>
> Interesting. The '\x{fffd}' part is clearly wrong even though the process
> survives. I can reproduce it. It's sensitive to the (seemingly unrelated)
> command line arguments.
Progress: this seems to be more or less equivalent to this case:
% perl -e 'binmode(STDOUT, ":encoding(ascii)"); print(("A"x shift) . "รค\n")'
1023
"\x{fffd}" does not map to ascii at -e line 1.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x{fffd}"\x{fffd}"
does not map to ascii at -e line 1.
"\x{00a4}" does not map to ascii at -e line 1.
\x{fffd}\x{00a4}
which should give \x{00c3}\x{00a4} at the end and does with other
values of the argument.
It happens when there's a multibyte character on the buffer boundary
in PerlIOBuf_write(), so it flushes in the middle of the character.
It seems sort of a user error for trying to squeeze non-ASCII characters
in an ASCII filehandle (which is what we have in the EU::MM case too;
see also https://rt.cpan.org/Ticket/Display.html?id=106461 )
Still no test case for the apparent memory corruption that leads to
the crashes...
--
Niko Tyni nt...@debian.org
