Skip Menu |

This queue is for tickets about the Imager CPAN distribution.

Report information
The Basics
Id: 27668
Status: resolved
Priority: 0/
Queue: Imager

People
Owner: Nobody in particular
Requestors: mb [...] imp.ch
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Crashes reading animated gifs
Date: Thu, 21 Jun 2007 00:09:40 +0200 (CEST)
To: bug-Imager [...] rt.cpan.org
From: Martin Blapp <mb [...] imp.ch>
Sometime im[0] or im[1] is still ok, and im[2] is then corrupted. (gdb) bt #0 i_tags_destroy (tags=0xdc17024) at tags.c:176 #1 0x28572a5c in i_img_exorcise (im=0xdc17000) at image.c:407 #2 0x28572af9 in i_img_destroy (im=0xdc17000) at image.c:438 #3 0x28591a1d in free_images (imgs=0xd50cfe0, count=5) at gif.c:424 #4 0x28593fb3 in i_readgif_multi_low (GifFile=0xd5673c0, count=0xbfbfe658, page=-1) at gif.c:554 #5 0x28594398 in i_readgif_multi (fd=21, count=0xbfbfe658) at gif.c:896 #6 0x285943f1 in i_readgif_multi_wiol (ig=0xd567380, count=0xbfbfe658) at gif.c:850 #7 0x2855c8aa in XS_Imager_i_readgif_multi_wiol (cv=0x93c25cc) at Imager.xs:2869 #8 0x28104cec in Perl_pp_entersub () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #9 0x280fddad in Perl_runops_standard () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #10 0x2812e354 in S_docatch () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #11 0x280fddad in Perl_runops_standard () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #12 0x280a8810 in S_call_body () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #13 0x280ad012 in Perl_call_sv () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #14 0x280ad2cc in Perl_call_pv () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so #15 0x280ad379 in Perl_call_argv () from /idms/lib/perl5/5.8.8/mach/CORE/libperl.so (gdb) f 1 #1 0x28572a5c in i_img_exorcise (im=0xdc17000) at image.c:407 407 i_tags_destroy(&im->tags); (gdb) p im[0] $6 = {channels = 269488144, xsize = 269488144, ysize = 269488144, bytes = 269488144, ch_mask = 269488144, bits = 269488144, type = 269488144, virtual = 269488144, idata = 0x10101010 <Address 0x10101010 out of bounds>, tags = {count = 269488144, alloc = 269488144, tags = 0x10101010}, ext_data = 0x10101010, i_f_ppix = 0x10101010, i_f_ppixf = 0x10101010, i_f_plin = 0x10101010, i_f_plinf = 0x10101010, i_f_gpix = 0x10101010, i_f_gpixf = 0x10101010, i_f_glin = 0x10101010, i_f_glinf = 0x10101010, i_f_gsamp = 0x10101010, i_f_gsampf = 0x10101010, i_f_gpal = 0x10101010, i_f_ppal = 0x10101010, i_f_addcolors = 0x10101010, i_f_getcolors = 0x10101010, i_f_colorcount = 0x10101010, i_f_maxcolors = 0x10101010, i_f_findcolor = 0x10101010, i_f_setcolors = 0x10101010, i_f_destroy = 0x10101010} Martin Blapp, <mb@imp.ch> <mbr@FreeBSD.org> ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: <finger -l mbr@freebsd.org> PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------
From: TONYC [...] cpan.org
On Wed Jun 20 18:09:55 2007, mb@imp.ch wrote: Show quoted text
> > Sometime im[0] or im[1] is still ok, and im[2] is then corrupted. > > (gdb) bt > #0 i_tags_destroy (tags=0xdc17024) at tags.c:176 > #1 0x28572a5c in i_img_exorcise (im=0xdc17000) at image.c:407 > #2 0x28572af9 in i_img_destroy (im=0xdc17000) at image.c:438 > #3 0x28591a1d in free_images (imgs=0xd50cfe0, count=5) at gif.c:424 > #4 0x28593fb3 in i_readgif_multi_low (GifFile=0xd5673c0, > count=0xbfbfe658, page=-1) at gif.c:554
Hi, This looks like a failure path, since free_images() is normally called to release any already read in images when returning a failure of some sort. Reading a normal valid animated GIF normally doesn't cause any problems, as Imager reads those as part of its test suite. Could you please provide: - the GIF (or some GIF) file that produces the problem above - the platform (eg. FreeBSD 6.2) - whether you're using giflib or libungif and which version Thanks Tony
Subject: Re: [rt.cpan.org #27668] Crashes reading animated gifs
Date: Thu, 21 Jun 2007 01:57:42 +0200 (CEST)
To: via RT <bug-Imager [...] rt.cpan.org>
From: Martin Blapp <mb [...] imp.ch>
Hi, Show quoted text
> - the GIF (or some GIF) file that produces the problem above > - the platform (eg. FreeBSD 6.2) > - whether you're using giflib or libungif and which version
It's not that easy. We don't have the gifs available since those are embeeded in mails, which tempfail. I'll try to catch one, but its difficult. Platform is FreeBSD 6.2, libungif 4.1.4 Of course I've got more coredumps available, we get 10-20 crashes the day. This is another crash path: (gdb) frame 4 #4 0x2855efb3 in i_readgif_multi_low (GifFile=0xdb2f040, count=0xbfbfe4e8, page=-1) at gif.c:700 700 free_images(results, *count); (gdb) list 695 else { 696 for (i = 0; i < Height; i++) { 697 if (DGifGetLine(GifFile, GifRow, Width) == GIF_ERROR) { 698 gif_push_error(); 699 i_push_error(0, "Reading GIF line"); 700 free_images(results, *count); 701 DGifCloseFile(GifFile); 702 myfree(GifRow); 703 return NULL; 704 } (gdb) p **results $7 = {channels = 0, xsize = 0, ysize = 0, bytes = 23472, ch_mask = 4294967295, bits = i_8_bits, type = i_palette_type, virtual = 0, idata = 0x0, tags = { count = 14, alloc = 20, tags = 0x8073200}, ext_data = 0x0, i_f_ppix = 0x2853f464 <i_ppix_d>, i_f_ppixf = 0x2853fccc <i_ppixf_fp>, i_f_plin = 0x2853f5e4 <i_plin_d>, i_f_plinf = 0x2853fdac <i_plinf_fp>, i_f_gpix = 0x2853f4d4 <i_gpix_d>, i_f_gpixf = 0x2853fd44 <i_gpixf_fp>, i_f_glin = 0x2853f54c <i_glin_d>, i_f_glinf = 0x2853fed0 <i_glinf_fp>, i_f_gsamp = 0x2854f3d8 <i_gsamp_p>, i_f_gsampf = 0x2853ffd0 <i_gsampf_fp>, i_f_gpal = 0x2854f530 <i_gpal_p>, i_f_ppal = 0x2854f590 <i_ppal_p>, i_f_addcolors = 0x2854f5f0 <i_addcolors_p>, i_f_getcolors = 0x2854f640 <i_getcolors_p>, i_f_colorcount = 0x2854f6c4 <i_colorcount_p>, i_f_maxcolors = 0x2854f6d4 <i_maxcolors_p>, i_f_findcolor = 0x2854f73c <i_findcolor_p>, i_f_setcolors = 0x2854f6e4 <i_setcolors_p>, i_f_destroy = 0x2854f128 <i_destroy_p>} (gdb) p *results[0] $8 = {channels = 0, xsize = 0, ysize = 0, bytes = 23472, ch_mask = 4294967295, bits = i_8_bits, type = i_palette_type, virtual = 0, idata = 0x0, tags = { count = 14, alloc = 20, tags = 0x8073200}, ext_data = 0x0, i_f_ppix = 0x2853f464 <i_ppix_d>, i_f_ppixf = 0x2853fccc <i_ppixf_fp>, i_f_plin = 0x2853f5e4 <i_plin_d>, i_f_plinf = 0x2853fdac <i_plinf_fp>, i_f_gpix = 0x2853f4d4 <i_gpix_d>, i_f_gpixf = 0x2853fd44 <i_gpixf_fp>, i_f_glin = 0x2853f54c <i_glin_d>, i_f_glinf = 0x2853fed0 <i_glinf_fp>, i_f_gsamp = 0x2854f3d8 <i_gsamp_p>, i_f_gsampf = 0x2853ffd0 <i_gsampf_fp>, i_f_gpal = 0x2854f530 <i_gpal_p>, i_f_ppal = 0x2854f590 <i_ppal_p>, i_f_addcolors = 0x2854f5f0 <i_addcolors_p>, i_f_getcolors = 0x2854f640 <i_getcolors_p>, i_f_colorcount = 0x2854f6c4 <i_colorcount_p>, i_f_maxcolors = 0x2854f6d4 <i_maxcolors_p>, i_f_findcolor = 0x2854f73c <i_findcolor_p>, i_f_setcolors = 0x2854f6e4 <i_setcolors_p>, i_f_destroy = 0x2854f128 <i_destroy_p>} (gdb) p *results[1] $9 = {channels = 0, xsize = 0, ysize = 0, bytes = 23472, ch_mask = 4294967295, bits = i_8_bits, type = i_palette_type, virtual = 0, idata = 0x0, tags = { count = 13, alloc = 20, tags = 0x8073400}, ext_data = 0x0, i_f_ppix = 0x2853f464 <i_ppix_d>, i_f_ppixf = 0x2853fccc <i_ppixf_fp>, i_f_plin = 0x2853f5e4 <i_plin_d>, i_f_plinf = 0x2853fdac <i_plinf_fp>, i_f_gpix = 0x2853f4d4 <i_gpix_d>, i_f_gpixf = 0x2853fd44 <i_gpixf_fp>, i_f_glin = 0x2853f54c <i_glin_d>, i_f_glinf = 0x2853fed0 <i_glinf_fp>, i_f_gsamp = 0x2854f3d8 <i_gsamp_p>, i_f_gsampf = 0x2853ffd0 <i_gsampf_fp>, i_f_gpal = 0x2854f530 <i_gpal_p>, i_f_ppal = 0x2854f590 <i_ppal_p>, i_f_addcolors = 0x2854f5f0 <i_addcolors_p>, i_f_getcolors = 0x2854f640 <i_getcolors_p>, i_f_colorcount = 0x2854f6c4 <i_colorcount_p>, i_f_maxcolors = 0x2854f6d4 <i_maxcolors_p>, i_f_findcolor = 0x2854f73c <i_findcolor_p>, i_f_setcolors = 0x2854f6e4 <i_setcolors_p>, i_f_destroy = 0x2854f128 <i_destroy_p>} (gdb) p *results[2] $10 = {channels = 269488144, xsize = 269488144, ysize = 269488144, bytes = 269488144, ch_mask = 269488144, bits = 269488144, type = 269488144, virtual = 269488144, idata = 0x10101010 <Address 0x10101010 out of bounds>, tags = {count = 269488144, alloc = 269488144, tags = 0x10101010}, ext_data = 0x10101010, i_f_ppix = 0x10101010, i_f_ppixf = 0x10101010, i_f_plin = 0x10101010, i_f_plinf = 0x10101010, i_f_gpix = 0x10101010, i_f_gpixf = 0x10101010, i_f_glin = 0x10101010, i_f_glinf = 0x10101010, i_f_gsamp = 0x10101010, i_f_gsampf = 0x10101010, i_f_gpal = 0x10101010, i_f_ppal = 0x10101010, i_f_addcolors = 0x10101010, i_f_getcolors = 0x10101010, i_f_colorcount = 0x10101010, i_f_maxcolors = 0x10101010, i_f_findcolor = 0x10101010, i_f_setcolors = 0x10101010, i_f_destroy = 0x10101010} (gdb) p *results[3] $11 = {channels = 225247008, xsize = 0, ysize = 225247024, bytes = 3, ch_mask = 0, bits = 225247040, type = i_direct_type, virtual = 0, idata = 0x0, tags = {count = 142, alloc = 225247056, tags = 0x0}, ext_data = 0x0, i_f_ppix = 0, i_f_ppixf = 0x2, i_f_plin = 0xd6cff60, i_f_plinf = 0, i_f_gpix = 0, i_f_gpixf = 0, i_f_glin = 0, i_f_glinf = 0xd98c2a0, i_f_gsamp = 0, i_f_gsampf = 0, i_f_gpal = 0, i_f_ppal = 0x1c5, i_f_addcolors = 0xd98c2c0, i_f_getcolors = 0, i_f_colorcount = 0, i_f_maxcolors = 0, i_f_findcolor = 0x54, i_f_setcolors = 0xd6cff70, i_f_destroy = 0} (gdb) p *results[4] Cannot access memory at address 0x6000 (gdb) p *results[5] Cannot access memory at address 0x42 -- Martin
Subject: Re: [rt.cpan.org #27668] Crashes reading animated gifs
Date: Thu, 21 Jun 2007 11:27:54 +1000
To: Martin Blapp via RT <bug-Imager [...] rt.cpan.org>
From: tonyc [...] cpan.org
On Wed, Jun 20, 2007 at 07:58:09PM -0400, Martin Blapp via RT wrote: Show quoted text
> > Queue: Imager > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=27668 > > > > Hi, >
> > - the GIF (or some GIF) file that produces the problem above > > - the platform (eg. FreeBSD 6.2) > > - whether you're using giflib or libungif and which version
> > It's not that easy. We don't have the gifs available since > those are embeeded in mails, which tempfail. I'll try to catch one, but its > difficult.
Ok, thanks. One option might be to add code to your image processing that saves the image content to a file, and deletes it after Imager reads it successfully - any leftovers should be the images causing a crash. I'll try running some fuzz tests (randomly damaged files) to see if I can cause a crash. Tony
Subject: Re: [rt.cpan.org #27668] Crashes reading animated gifs
Date: Thu, 21 Jun 2007 22:30:17 +0200 (CEST)
To: via RT <bug-Imager [...] rt.cpan.org>
From: Martin Blapp <mb [...] imp.ch>
Hi, Hrmpf. After more investigations, I guess I found the problem. It was a local patch I added in version 0.48 and it was partly done wrong. Sorry for the noise. It I get other crashes with some pics I'll let you know. You can close this PR. -- Martin
On Thu Jun 21 16:30:41 2007, mb@imp.ch wrote: Show quoted text
> > Hi, > > Hrmpf. After more investigations, I guess I found the problem. It > was a local patch I added in version 0.48 and it was partly done > wrong. > > Sorry for the noise. > > It I get other crashes with some pics I'll let you know.
Ok, thanks. The fuzz testing revealed some failure path memory leaks, so it was useful anyway :) Tony