Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-22 Thread DRC
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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-22 Thread DRC
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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-22 Thread DRC
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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-14 Thread DRC
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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-07 Thread DRC
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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-07 Thread DRC
: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

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

2014-11-07 Thread DRC
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

Bug#601386: Etch and squeeze

2010-10-26 Thread DrC
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