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