#164 Crash on fake jpg

open
Hervé Drolon
None
5
2012-10-31
2010-12-03
Mihail Naydenov
No

The supplied image crashes FreeImage on loading.

...it seams it might be libjpeg that is actually crashing, but I can't verify this myself.

Discussion

1 2 > >> (Page 1 of 2)
  •  
    Attachments
  • Hervé Drolon
    Hervé Drolon
    2010-12-05

    Your file is a C++ header file and not a JPG file.
    When trying to load this file, an error is immediately thrown :
    "Not a JPEG file: starts with 0x23 0x69"
    and the library returns NULL.

    There's no crash occurring with this image.

     
  • Humm, On my machine it crashes with "thrown an instance of 'int'" while jpeg_read_header (which, i know it is impossible, but this is the case).

    BTW I know its not an jpg, I created it for a stress test.

    Compiled 3.15.1 with minGW.

     
  • Well, after a day of digging here is the result:

    1. The issue is eminent on recent versions of GCC.
    2. The issue is by no means invalid. The reason to occur is because
      FI is throwing C++ exceptions from inside C code, which is WRONG
    3. The issue was hidden so far on gcc because, at least on windows, until 4.4 GCC used setjmp longjmp to impl exception, which is compatible with both c and c++
    4. To "solve" the issue one must add
      -fexceptions to the c lib that throws. In our case
      LibJPEG must be compiled with the -fexceptions flag
      And FreeImage.dll recompiled.

    (probably the right solution is to use setjmp/longjmp instead of trow, but that is a bit anti-kiss)

    This information should find its place in the mingw makefile!

    thanks

    BTW if not handled this issue will crash on any load fail or jpeg transform fail. This is, the error report for now is broken under mingw 4.4+.
    Also there are no guarantee this will not happen on newer versions of ms compiler also or any other compiler or platform. As said, FI is doing something wrong, though not uncommon, at the very least
    new releases, using new compiler or platform, should be tested for error report fails!

     
  • Hervé Drolon
    Hervé Drolon
    2011-01-16

    Can you provide a patch against MinGW or GCC ?
    I'm not able to reproduce the problem with my (rather old) version of gcc.
    I suppose we have to patch both Makefile.mingw and Makefile.gnu, as well as Makefile.fip ?

    Hervé

     
  • Sadly I cant write makefiles. I even dont use them at all - I use imported VS project in CodeLight/code::blocks and set up it manually.

    So I cant be of any more help :(

     
  • Just a longshot, it seems the signature FFD8 is absent.

     
  • @petersen4

    As said it is a fake image (an arbitrary file renamed as jpeg), created to stress-test.

     
  • To me, what mnaydenov said "..it seams it might be libjpeg that is actually crashing, but I can't verify this myself" has a certain reason basing on what we encountered a little while ago -- in that case a bug had been found there in reading a tag with empty entry (despite tag length of 2 was correctly entered).

    It seems that the test file doesn't have any tag detectable. Then, would it be likely that libjpeg crashes on it.

     
  • For this, and one other image, I have debug the code and the crash is indeed, as I described it - the throw from our error handler.
    The actual error does not matter, libjpeg is handling the situation correctly so far.

     
1 2 > >> (Page 1 of 2)