I don't know why you would expect me to have tried that, given that
there was no reasonable expectation that I would know any of that
information prior to now.
But I did just try it, and it works fine.
I will re-iterate:
You need to produce a test case that demonstrates this failure using
only libjpeg-turbo. You cannot expect me to spend any time on this
until it is proven that it is my bug and not someone else's. Sometimes
issues like this can be caused by the overlying application, even though
the bug manifests in the underlying library.
On 11/7/14 12:47 PM, roucaries bastien wrote:
On Fri, Nov 7, 2014 at 6:36 PM, DRC <dcomman...@users.sourceforge.net> wrote:
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.
Did you try to compile libjpeg-turbo with -fstack-protector-all ggc
flags. Debian do it and thus detect stack overflow (valgrind is not at
help here).
BTW could you nevertheless get a glimpse at the last backtrace. I but
a watch point on the canary (I tried but because this function is
called a lot of time I may be missing something) using method [1]. It
seems the code that smash the code is at encode_one_block line 543:
kloop(59); kloop(52); kloop(45); kloop(38); kloop(31); kloop(39);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
