We have seen a trend in tiff files rendered in GS 9.00 and 9.02 that was not present in GS 8.63. In this case some tiffs are being rendered without the first 8 bytes of the tiff header. This happens rarely, we are seeing a failure rate of about 1 page out of every 100,000 pages rendered, but is fairly consistent at that rate. The tiff renders that failed do not fail if rerun so we have implemented a separate parser to find these as they occur and re-render as needed. I have been able to prepend the missing fields into the offending tiff files with a hex editor and this does seem to repair the documents. Our current parameters in GS. -dNOPAUSE -q -dBATCH -sDEVICE=tiffg4 -r300x300 -dNOCIE=20 -sOutputFile=<outputfilepath> <sourcePdfPath>
Assigned to Marcos to try and reproduce (though 1 out of 100,000 is going to be hard).
Could you send me a sample input file? Also, could you confirm that a bad file is the same as a correct TIFF file but just missing the first 8 bytes?
Created attachment 7637 [details] PDF (1.7) created with PDFLib 8.0.1p3 test data This is a test PDF created in the same manner as PDFs that have exhibited the bug in the past.
We have also continued to test for this bug in our system. We have created 4 machines with a clean Win XP sp3 install and only GS 9.02 installed, along with our tiffing package which calls GS with the parameters given earlier. File writes were made to an Isilon NAS. In our last run this setup created 5 failures out of 400,000 documents. The bug has been observed in both multipage and singlepage tiff formats. We have tried isolating out the NAS alone to check it for possibly generating the corrupted files and have run 1.2 million file writes in a tight loop without generating a failure. Additionally the nature of the corruption being specifically the first 8 bytes of the header tends to point back to software. I spent a little time looking at some of the Tiff creation code in GS but, I ran out of time to do sufficient code spelunking. I'll likely come back around to this when I can get a free moment from my current project.
(In reply to comment #4) > We have tried isolating out the NAS alone to > check it for possibly generating the corrupted files and have run 1.2 million > file writes in a tight loop without generating a failure. Additionally the > nature of the corruption being specifically the first 8 bytes of the header > tends to point back to software. > My testing on a none NAS system matches yours; I wasn't able to induce a failure. Since the NAS is a necessary part of the setup I'm not going to be able to reproduce this. I suggest testing to see if the problem is limited to TIFF devices. Replace the tiffg4 DEVICE parameter with pbmraw and see if any of the output files are bad. This will isolate the issue to the core Ghostscript code versus the TIFF library.
Am closing due to lack of ability to reproduce this. Please reopen if you are able to find a more consistent test case.