On Fri, Nov 7, 2014 at 4:57 PM, DRC <dcomman...@users.sourceforge.net> wrote:
> Happy to fix it, but I need to be able to reproduce it first, using only
> libjpeg-turbo. Currently I cannot. I tried running
Here a backtrace, do you want to get some argument of the call function ?
#0 0x00007ffff7067107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff70684e8 in __GI_abort () at abort.c:89
#2 0x00007ffff70a5044 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff7128137 in __GI___fortify_fail
(msg=msg@entry=0x7ffff7195673 "stack smashing detected") at
fortify_fail.c:31
#4 0x00007ffff7128100 in __stack_chk_fail () at stack_chk_fail.c:28
#5 0x00007ffff39d7553 in encode_mcu_huff (cinfo=0x7fffffff42e0,
MCU_data=0x63a450) at jchuff.c:641
#6 0x00007ffff39ca717 in compress_output (cinfo=0x7fffffff42e0,
input_buf=<optimized out>) at jccoefct.c:381
#7 0x00007ffff39ca006 in jpeg_finish_compress (cinfo=0x7fffffff42e0)
at jcapimin.c:183
#8 0x00007ffff3c222d0 in WriteJPEGImage (image_info=0x2c0c,
image=0x2c0c) at ../../coders/jpeg.c:2810
#9 0x00007ffff79aa1bc in WriteImage (image_info=0x60e530,
image=0x626070) at ../../magick/constitute.c:1114
#10 0x00007ffff79aa87a in WriteImages (image_info=<optimized out>,
images=<optimized out>, filename=<optimized out>, exception=0x604e10)
at ../../magick/constitute.c:1327
#11 0x00007ffff763bc81 in ConvertImageCommand (image_info=0x4, argc=5,
argv=0x604810, metadata=0xffffffffffffffff, exception=0x0) at
../../wand/convert.c:3215
#12 0x00007ffff76a5ee7 in MagickCommandGenesis
(image_info=image_info@entry=0x604f90, command=0x400810
<ConvertImageCommand@plt>, argc=argc@entry=5,
argv=argv@entry=0x7fffffffe118,
metadata=metadata@entry=0x0, exception=exception@entry=0x604e10)
at ../../wand/mogrify.c:168
#13 0x0000000000400887 in ConvertMain (argv=0x7fffffffe118, argc=5) at
../../utilities/convert.c:81
#14 main (argc=5, argv=0x7fffffffe118) at ../../utilities/convert.c:92
>
> jpegtran -optimize -rotate 270 003632r270.jpg >out.jpg
>
> and
>
> jpegtran -progressive -optimize -rotate 270 003632r270.jpg >out.jpg
>
> with valgrind, and no issues were detected.
>
> I also tried the convert command line listed above, and with my (admittedly
> older) version of ImageMagick, no issues were detected. This leads me to
> suspect an issue with ImageMagick, not libjpeg-turbo. Furthermore, Mozilla
> bangs on the -optimize switch a tremendous amount, since that switch is
> enabled by default in their mozjpeg encoder (mozjpeg is focused on getting
> the absolute best compression ratio possible-- at the expense of like a 50x
> drop in performance-- so they enable progressive & optimize by default, as
> well as include other extensions like jpgcrush and trellis coding that
> aren't in libjpeg-turbo.) Furthermore, there is nothing about the optimized
> (multi-pass) Huffman coding feature that is different between libjpeg-turbo
> and libjpeg, so if this is genuinely a bug in libjpeg-turbo, it is likely to
> exist in libjpeg as well. Our optimizations affect only single-pass Huffman
> coding.
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
