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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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++
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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é
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
FI is throwing C++ exceptions from inside C code, which is WRONG
-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!
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.
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.
But are these for the libjpeg. It is it, that must be rebuild with -fexceptions, not (only) FreeImage.
Hi,
the "-fexceptions" is applied to all C files, so I suppose this should solve the problem ?
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.