I want exactly what I asked for: a way to reproduce this issue.
Currently I cannot. A backtrace from your machine is not helpful, as it
does not tell me anything regarding how the library is being used by
ImageMagick.
On 11/7/14 11:26 AM, roucaries bastien wrote:
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
