Chris Gravely

Sorry for the slow response. The fix looks fine to me

A possible alternative I can think of would be to implement JPEGCoder as a C-callable C++ subsystem, which would allow you to use try...catch and throw a C++ exception instead of using setjmp/longjmp. Having said that, in some situations the exception would get thrown through intermediate JPEG code, which lives in a separate library, and that might complicate things.

It looks as though ISO-IEC 9899 doesn't allow assignment of the setjmp result, so it might be better to remove the assignment and its associated logging, as it's possible this might cause problems in the future.

I've replaced libjpeg-turbo's jpeg library with an IJG one (I used jpeg-9d as that's the latest). I get crashes similar to my originals. Do you know anything about Cygwin's setjmp/longjmp implementations. I know mingw64 uses MSVCRT implementations, but I'm wondering if the Cygwin library providing the POSIX environment has its own implementation. If so, that could explain why the test works when built under Cygwin.

The problem is directly related to '-define jpeg:max-warnings=0'; there's only one warning issued when reading the jpeg file, so longjmp isn't called when max-warnings is one or greater.

There are no warnings or errors when I recompile coders/jpeg.c and rebuild the executables

I've made the following changes: Rebuilt everything except coders/jpeg.c with CFLAGS = -fopenmp -g -O0 -Wall Added pragmas around JPEGDecodeMessageHandler to force it to compile -O0 (so stuff doesn't get inlined out in the stack traces). gdb_O0.txt was produced compiling coders/jpeg.c with CFLAGS = -fopenmp -g -O0 -Wall gdb_Og.txt was produced compiling coders/jpeg.c with CFLAGS = -fopenmp -g -Og -Wall -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-defer-pop -fno-forward-propagate...

Added zipped jpeg file