#164 Crash on fake jpg

open
None
5
2012-10-31
2010-12-03
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

  • Mihail Naydenov

    Mihail Naydenov - 2010-12-03
     
  • 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.

     
  • Mihail Naydenov

    Mihail Naydenov - 2010-12-06

    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.

     
  • Mihail Naydenov

    Mihail Naydenov - 2010-12-28

    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é

     
  • Mihail Naydenov

    Mihail Naydenov - 2011-01-17

    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 :(

     
  • Johnny Petersen

    Johnny Petersen - 2011-01-17

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

     
  • Mihail Naydenov

    Mihail Naydenov - 2011-01-17

    @petersen4

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

     
  • Johnny Petersen

    Johnny Petersen - 2011-01-21

    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.

     
  • Mihail Naydenov

    Mihail Naydenov - 2011-01-22

    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.

     
  • Hervé Drolon

    Hervé Drolon - 2011-01-23

    Looking at the makefiles, I can see :

    Makefile.gnu
    CFLAGS ?= -O3 -fPIC -fexceptions -fvisibility=hidden -DNO_LCMS

    Makefile.mingw
    CFLAGS ?= -O3 -fexceptions -DNDEBUG $(WIN32_CFLAGS)

    So the "-fexceptions" option is already handled by the makefiles.

     
  • Mihail Naydenov

    Mihail Naydenov - 2011-01-24

    But are these for the libjpeg. It is it, that must be rebuild with -fexceptions, not (only) FreeImage.

     
  • Hervé Drolon

    Hervé Drolon - 2011-01-30

    Hi,

    the "-fexceptions" is applied to all C files, so I suppose this should solve the problem ?

     
  • Mihail Naydenov

    Mihail Naydenov - 2011-01-31

    Well, I guess it already solved then. More or less.
    As said this might pop up in VS too, and certainly for people like me building without makefiles.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks