Correctly handle errors when starting jpeg codec

The current implementation treats both returning false and longjmp'ing
out of jpeg_start_decompress as indicating that the decompression has
paused and needs more data. This is incorrect, in reality only the
false return value indicates this. The longjmp path indicates a fatal
error in the processing of the jpeg. The default implementation
actually calls exit() in this case, and the documentation explicitly
calls out that in this case recovery isn't possible and the decode
process will have to start from scratch.

This resolves a situation where the progressive decoder would get a
malformed jpeg and keep on grabbing blocks from it and try to start
decoding it. This would eventually fail when it ran out of data to
read, but would cause a large memory leak and a crash on the MSAN
fuzzers.

BUG=pdfium:986,chromium:798665

Change-Id: Ifd2ed7a2dc46fa20bab34e9c461a8d4c4718c4d7
Reviewed-on: https://pdfium-review.googlesource.com/23072
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>

0 files changed, 0 insertions, 0 deletions