tream patch to subversion trunk, as well as branches/1.4.x and
branches/1.3.x.
On 11/22/14 2:06 PM, roucaries bastien wrote:
On Sat, Nov 22, 2014 at 6:58 PM, DRC wrote:
I can readily reproduce the failure with the supplied test case, but what
I'm tripping on right now is understanding why
happen again in the future.
On 11/22/14 2:06 PM, roucaries bastien wrote:
On Sat, Nov 22, 2014 at 6:58 PM, DRC wrote:
I can readily reproduce the failure with the supplied test case, but what
I'm tripping on right now is understanding why a Huffman-encoded block can
grow so much larger
I can readily reproduce the failure with the supplied test case, but
what I'm tripping on right now is understanding why a Huffman-encoded
block can grow so much larger than the size of the source block (128
bytes.) While this test case is very unusual, there may be others out
there, and I wan
ocal buffer is overrun. At this point,
I'm stymied. If someone can point me to the place in the ImageMagick
code where this is happening, I can at least take a look at how they're
calling the transformer and see how it differs from how I'm calling the
transformer.
On 11/1
s more then 128 but this info should probably
> give the maintainers of libjpegturbo a bit more information to
> investigate this issue.
>
>> On Fri, Nov 7, 2014 at 9:33 PM, DRC wrote:
>> I don't know why you would expect me to have tried that, given that there
>> was no r
es bastien wrote:
On Fri, Nov 7, 2014 at 6:36 PM, DRC 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
:57 PM, DRC 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 0x77067107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix
Happy to fix it, but I need to be able to reproduce it first, using only
libjpeg-turbo. Currently I cannot. I tried running
jpegtran -optimize -rotate 270 003632r270.jpg >out.jpg
and
jpegtran -progressive -optimize -rotate 270 003632r270.jpg >out.jpg
with valgrind, and no issues were de
exit() is called by error_exit() in jerror.c, which is part of the
libjpeg source. error_exit() is part of the standard error manager for
libjpeg. Applications do not have to use that error manager. The
TurboJPEG wrapper, specifically, uses its own custom error manager that
will catch errors
Just FYI-- Fedora has scrapped its plans to update to the libjpeg v8
ABI, and further research
(http://www.libjpeg-turbo.org/About/SmartScale) has raised
questions/concerns regarding whether the features introduced in libjpeg
v7 and later really solve any problems that couldn't already be solve
ize for the success of our codec.
I have never done anything other than attempt to meet the demands of
the open source community, and libjpeg-turbo is thus a product of that
community.
DRC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug-hunting at this level of detail is new to me, so forgive me if any
of this is rubbish. It seems to me that:
Debian 4.0 was broken in the sense that scripts edited by its version of
nano could fail. It seems the backslash continuation line syntax was
not preserved. This old version of nano c
12 matches
Mail list logo
