While testing the files from customer394, 3 files were found that give problems involving OpenJPEG. The most significant is with: tests_private/pdf/customer394/problems/normal_590.pdf Under both MuPDF and gs this causes a SEGV. We ought to fix this. The other two files result in us not rendering the image in either gs or mupdf, where acrobat manages to at least display something; given that fact the files are (I believe) broken, these are probably not really problems, but I mention them here for completeness. tests_private/pdf/customer394/problems/normal_625.pdf Acrobat manages to render that without giving an error, but it looks suspiciously like a corrupt image to me. tests_private/pdf/customer394/problems/normal_871.pdf Acrobat at least gives a partial image before giving an error.
FYI: Our patchset against OpenJPEG is at http://code.google.com/p/sumatrapdf/source/browse/trunk/ext/_patches/openjpeg.patch If that doesn't help and nobody else is working on this issue, I could look into fixing at least the SEGV and get the fix upstream - provided that I can get access to the offending documents.
(In reply to comment #1) > FYI: Our patchset against OpenJPEG is at > http://code.google.com/p/sumatrapdf/source/browse/trunk/ext/_patches/openjpeg.patch > > If that doesn't help and nobody else is working on this issue, I could look > into fixing at least the SEGV and get the fix upstream - provided that I can > get access to the offending documents. Shailesh has started to work on this bug (in fact he started before the bug was created - the bug was created to track the work). If he stops work on it, I'll put a note here so you know it's safe to continue. Thanks for your interest, but I'd hate to see your time wasted!
The 590 file does not trigger the j2k_read_cox function so tccp->numresolutions remains set at its default value of 0, this in turn means that when we reach the end of codestream marker j2k_read_eoc is called. As the first tile is decoded in j2k_read_eoc, there is a call to tcd_malloc_decode_tile which uses the zero numresolution value to allocate some memory, given the lack of error checking, later code then accesses the contents of the uninitialized memory and mayhem ensues. A patch will follow shortly.
Created attachment 8742 [details] Patch to prevent seg fault This patch prevents the seg fault by detecting the problem early and preventing the uninitialised memory access. The patch has been cluster tested.
Fixed in gs by: commit 29a16f87849a874cd872fc8e2beab2b3986eea51 Author: Robin Watts <robin.watts@artifex.com> Date: Thu Jul 12 13:29:24 2012 +0100 Bug 693171: Patch OpenJPEG to avoid SEGVs with broken files. Patch from Shailesh Mistry. In the case of corrupt files, tiles were failing to be allocated, leaving the code attempting to work with non existent tiles. The fix is to spot the failure, mark the tiles as being non-existence and then to check this before accessing them. Thanks Shelly! This will get rolled into the new thirdparty release we'll do in August and will fix mupdf too.
I just noted that you still seem to be using OpenJPEG 1.4. Does this SEGV also still occur with version 1.5? (IOW: If you can't share the mentioned normal_590.pdf with us, could you please open it in SumatraPDF v2.1.1 to see whether we need this patch as well? Thanks!)
(In reply to comment #6) > I just noted that you still seem to be using OpenJPEG 1.4. Does this SEGV also > still occur with version 1.5? (IOW: If you can't share the mentioned > normal_590.pdf with us, could you please open it in SumatraPDF v2.1.1 to see > whether we need this patch as well? Thanks!) We're using 1.5, so yes, the problem will occur with Sumatra too unless you take the patch.
(In reply to comment #7) > We're using 1.5 Thanks for the confirmation. Looks like I was confused by Ghostscript still using 1.4. BTW: Since you don't seem to have (publicly) reported this issue to the OpenJPEG developers, I've opened an issue to make sure that your fix gets merged upstream for the next release: http://code.google.com/p/openjpeg/issues/detail?id=159