(none) imager-devel
/ help / lists / applications / search /
 

Re: segfault in Imager 0.43

From: Tony Cook (
12434@xyz.molar.is)
Date: Mon 23 Aug 2004 - 23:31:33 GMT

  • Next message: Tony Cook: "Re: segfault in Imager 0.43"

    On Mon, Aug 23, 2004 at 08:57:19AM -0700, Peter Leonard wrote:
    >
    > As a follow-up:
    >
    > Further investigation shows that it's not the scale() call that causes the
    > borking. It's the call to $thumb->write().

    This does indeed seem to be a bug in Imager, here's a backtrace from
    the seg fault:

    (gdb) bt
    #0 0x401cc654 in hbsetup ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #1 0x401cc777 in translate_addi ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #2 0x401cb886 in translate_closest ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #3 0x401cb82e in quant_translate ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #4 0x401dd822 in i_writegif_low ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #5 0x401ddf8e in i_writegif_gen ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #6 0x401de1af in i_writegif_wiol ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #7 0x401a8101 in XS_Imager_i_writegif_wiol ()
       from /home/tony/dev/imager/maint/Imager/blib/arch/auto/Imager/Imager.so
    #8 0x0809c90c in Perl_pp_entersub ()

    writegif_wiol() is the main entry point for writing gifs on the C side
    of Imager.

    When converting to GIF the image is first converted to a paletted
    image, first a scan is done to produce a color table, then Imager
    does a translation from RGB to paletted using that table.

    It's crashing in the translation stage.

    I get the same result if I use a PNG file as input.

    I also get a crash if I call $thumb->to_paletted, so it's not a libungif
    problem.

    I'll try to debug this and put a fix in CVS.

    > > Strangely, removing the 'type' argument gets things to work, but the
    > > resulting image is not desireable (a 13924x118 gif).

    The size of the image is the result of the arguments you supplied to scale.

    Your image is 118 pixels wide and 1 pixel high.

    You asked for an image 1 pixel wide and 118 pixels high.

    The scale() method attempts to preserve the width to height ratio of
    images by default, and if your parameters aren't at the same aspect as
    the original image it will scale to the larger dimension, which is what
    has happened here.

    Tony Cook



  •