Bug#834961: Processed: tagging 834961

[Niko Tyni]

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   ntyni at debian.org