Bug#726600: otrs2: Internal server error when replying to email ticket
Niko Tyni
ntyni at debian.org
Tue Oct 29 19:56:03 UTC 2013
On Mon, Oct 28, 2013 at 08:05:01PM +0100, Salvatore Bonaccorso wrote:
> otrs2 seems to have an anoying (not easy to reproduce bug), which was
> reported against otrs2 (and which seems to appear after the perl
> 5.14.2 -> 5.18.1 update):
>
> http://bugs.debian.org/724972
> http://bugs.debian.org/726600
>
> Does this sound somewhere familiar to you, or does this ring a bell?
Yeah, Patrik mailed me about it too, I just didn't have the time earlier.
John Seymour's comment in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726600#75
seems helpful:
[Tue Oct 22 11:56:15 2013] -e: Strings with code points over 0xFF may not be mapped into in-memory file handles
[Tue Oct 22 11:56:15.193665 2013] [:error] [pid 8510] [Tue Oct 22 11:56:15 2013] -e: open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878.\n
A similar failure can be triggered with something like this:
perl -CO -Mstrict -we 'my $a = "\x{2660}"; open(my $h, ">>", \$a) or die "open failed: $!"; print $h "test\n"; close $h; print $a'
which dies with 5.18 but not with 5.14.
This is by design: the relevant perl5180delta entry is
PerlIO::scalar has been upgraded to 0.16.
The buffer scalar supplied may now only contain code pounts 0xFF or
lower. [perl #109828]
and the change is
http://perl5.git.perl.org/perl.git/commit/02c3c86bb8fe791df9608437f0844f9a8017e3b6
which was thoroughly discussed in the aforementioned ticket
https://rt.perl.org/Public/Bug/Display.html?id=109828
So the reproducing recipe presumably involves non-ASCII, non-latin1
characters in the ticket. Hope that helps a bit.
Not sure if this is a bug in MIME-Tools. My half hearted attempts to
trigger it by parsing a crafted UTF-8 email message weren't successful
(meaning MIME-Tools was behaving more or less correctly.)
So it needs something more complex to show up. I see OTRS,
Kernel/System/Encode.pm in particular, is using the Encode internal
functions _utf8_on() and _utf8_off() quite a bit. The root
problem might be somewhere there.
I can look at it more (time permitting) if somebody finds a way to
reproduce it.
--
Niko Tyni ntyni at debian.org
More information about the Perl-maintainers
mailing list