| Summary: | Ghostscript command hangs indefinitely | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | skom |
| Component: | PDF Interpreter | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 9.15 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Customer: | Word Size: | --- | |
| Attachments: | File to reproducing problem | ||
|
Description
skom
2014-11-01 16:00:10 UTC
We *do* emit warnings, which you have, in fact, copied into your bug report, several along the lines of: **** Unknown operator: '321334..41.102' looks like a malformed number, replacing with 0. That is clearly not a well formed number, and indicate a very broken PDF file. If IM is not allowing those to be seen under normal conditions, that's hardly our problem! In truth, I'm not sure if there's much we can do, we end up with some extremely large coordinates, but they *are* valid - and hanling that takes time. One of us will look into this in more details at some point. The file is badly broken. Several of the content streams have Flat errors which leads (I think) to the corrupted co-ordinates. In any event, this obviously is *not* a problem with the build process! I'll see if we can detect the flate errors. Thank you very much Well, we cannot use the zlib error, as we know from prior experience (see Bug #688716) that Acrobat ignores such errors. The problem seems to be that we end up with some truly enormous co-ordinates, as a result of the corruption in the PDF file, and the time is taken by GS trying to subdivide a curve into line segments, where the curve extends to a very extreme point. I don't think it has hung, but it may take an unrealistically long time to terminate. We can't use the large co-ordinate as an error as co-ordinates are real numbers in PDF and can vary to +/- 3.403 x 10^38, also in this case the large co-ordinates are less than the maximum fixed precision values in Ghostscript, so we can't catch an attempt to write outside the maximum area and abort. So the only realistic solution I can come up with is to have corrupted files throw an error (if -dPDFSTOPONERROR is set) instead of trying to recover. Commit b2a6decb294ca8c48c71da2211f3284b2334d921 implements that change. |