Perfect, this is easy to fix!
Am 30.09.2017 17:13 schrieb "Heiko Weber via RT" <bug-GD@rt.cpan.org>:
> Queue: GD
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=123157 >
>
> I see it is a duplicate of Bug #26146 for GD: _image_type
>
> Hm, it is from 2007, why does all of the Debian’s have that only GD::Image
> …
>
> # DO NOT EDIT! THIS FILE IS AUTOGENERATED BY GD/Image.pm.PLS
> package GD::Image;
>
> use strict;
> use GD;
> use Symbol 'gensym','qualify_to_ref';
> use vars '$VERSION';
> $VERSION = '2.38';
>
>
> > Am 30.09.2017 um 16:57 schrieb Heiko Weber <heiko@wecos.de>:
> >
> > I’ve steped into it with „perl -d“:
> >
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:149):
> > 149: return 'Png' if $magic eq "\x89PNG";
> > DB<2>
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:150):
> > 150: return 'Jpeg' if $magic eq "\377\330\377\340";
> > DB<2>
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:151):
> > 151: return 'Jpeg' if $magic eq "\377\330\377\341";
> > DB<2>
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:152):
> > 152: return 'Jpeg' if $magic eq "\377\330\377\355";
> > DB<2>
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:153):
> > 153: return 'Jpeg' if $magic eq "\377\330\377\356";
> > DB<2>
> > GD::Image::_image_type(/usr/lib/x86_64-linux-gnu/perl5/5.
> 24/GD/Image.pm:154):
> > 154: return 'Gif' if $magic eq "GIF8";
> >
> > and printed the first 4 bytes of the image:
> >
> > my $magic = substr($g, 0, 4);
> > $magic =~ s/(.)/sprintf("%o ", ord($1))/eg;
> > print $magic."\n";
> >
> > outputs:
> >
> > 377 330 377 333
> >
> >
> >
> >> Am 30.09.2017 um 16:40 schrieb Heiko Weber <heiko@wecos.de>:
> >>
> >> Hm, I enabled more warnings and got this on a third Debian Server:
> >>
> >> Invalid \0 character in pathname for open: ���\0C at
> /usr/lib/x86_64-linux-gnu/perl5/5.20/GD/Image.pm line 63, <GEN0> line
> 4873.
> >>
> >> But it doesn’t get killed on that machine, instead GD::Image->new()
> took about ~4 seconds and return undef … wondering, because it is a 8 core
> Intel Xeon 3.3 ...
> >>
> >> Looks like the ->new() assumes the given argument is a filename instead
> of binary data.
> >>
> >> Linux Debian-83-jessie-64-minimal 3.16.0-4-amd64 #1 SMP Debian
> 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux
> >>
> >> libgd-perl 2.53-1+b1
> >> libgd3:amd64 2.1.0-5+deb8u11
> >> libjpeg62-turbo:amd64 1:1.3.1-12
> >>
> >>> Am 30.09.2017 um 15:28 schrieb Heiko Weber <heiko@wecos.de>:
> >>>
> >>> No, on Debian Linux, run from bash or Apache /mod_perl via www.
> >>>
> >>> This image was uploaded by one of our users to a mod_perl database
> Web-application, the user noticed that his image wasn‘t accepted via
> Browser Upload. After looking at this I found Apache process kills in the
> logfiles. I added some more logging and was able to identify
> GD::Image->new() with that binary image data to be the problem.
> >>>
> >>> The application runs for years with any kind of images (jpeg, png,
> gif, ...). I‘ve no idea whats wrong with that image, because it can be read
> by libjpeg in C/C++ very well.
> >>>
> >>>
> >>>
> >>> Von unterwegs gesendet.
> >>>
> >>>> Am 30.09.2017 um 13:19 schrieb reini.urban@gmail.com via RT <
> bug-GD@rt.cpan.org>:
> idea.
> >>>>
> >>>> Am 30.09.2017 13:16 schrieb "Heiko Weber via RT" <bug-GD@rt.cpan.org
> >:
> way:
> >>>>>
> >>>>> my $f = IO::File->new('<"test_data/images/noexif.jpeg") || die
> 'unable
> >>>>> to open';
> >>>>> my $g = '';
> >>>>>
> >>>>> while (<$f>) {
> >>>>> $g .= $_;
> >>>>> }
> >>>>> my $gd = GD::Image->new($g);
> >>>>>
> >>>>> —
> >>>>>
> >>>>> Debian/wheezy:
> >>>>>
> >>>>> libgd-gd2-perl 1:2.46-3+b1
> >>>>> libgd2-xpm:amd64 2.0.36~rc1~dfsg-6.1+deb7u10
> >>>>> libjpeg8:amd64 8d-1+deb7u1
> >>>>>
> >>>>> Debian/stretch:
> >>>>>
> >>>>> libgd-perl 2.53-3
> >>>>> libgd3:amd64 2.2.4-2+deb9u2
> >>>>> libjpeg62-turbo:amd64 1:1.5.1-2
> >>>>>
> >>>>>
> >>>>>> Am 30.09.2017 um 07:33 schrieb Slaven_Rezic via RT <
> bug-GD@rt.cpan.org>:
> >>>>>>
> >>>>>> <URL:
https://rt.cpan.org/Ticket/Display.html?id=123157 >
> >>>>>>
> >>>>>>> On 2017-09-29 17:59:30, RURBAN wrote:
> >>>>>>> So this is a libgd bug, but I cannot repro it.
> >>>>>>> I tried the following libgd versions:
> >>>>>>> 2.0.33 2.1.0 2.1.1 2.2.0 2.2.1 2.2.2 2.2.3 2.2.4 2.3.0-dev
> >>>>>>>
> >>>>>>> Which gd version do you have?
> >>>>>>> My test:
> >>>>>>>
> >>>>>>> $image = GD::Image->newFromJpeg("test_data/images/noexif.jpeg");
> >>>>>>> ok($image, 'exif-stripped jpeg');
> >>>>>>>
> >>>>>>
> >>>>>> The linux kernel signatures suggest that Debian/stretch and
> >>>>> Debian/wheezy were used. However I also could *not* reproduce the
> problem
> >>>>> on these systems with system perl:
> >>>>>>
> >>>>>> * Debian/wheezy
> >>>>>> * libgd2-xpm 2.0.36~rc1~dfsg-6.1+deb7u10
> >>>>>> * libjpeg8 8d-1+deb7u1
> >>>>>> * Debian/stretch
> >>>>>> * libgd3 2.2.4-2+deb9u2
> >>>>>> * libjpeg62-turbo 1:1.5.1-2
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
![Fri Sep 29 04:41:21 2017 (79.7k) by heiko [...] wecos.de](/Ticket/Attachment/1750265/941539/Hamburg_2.jpeg){kind=link}