The supplied image crashes FreeImage on loading.
...it seams it might be libjpeg that is actually crashing, but I can't verify this myself.
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:
(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!
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!
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 ?
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.
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.