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