Created attachment 582020 [details] XPS document Description of problem: I have a XPS file generated by Windows' file printer functionality. Evince's thumbnail program doesn't seem to handle it well and loops indefinitely eating 100% CPU (and heating up my laptop) until I kill the process. Version-Release number of selected component (if applicable): evince-3.4.0-2.fc17.x86_64 How reproducible: Always $ evince-thumbnailer -s 128 file:///home/foo/engine-codes.xps test.tmp Steps to Reproduce: 1. Run the command above with the XPS file attached to this bug. 2. 3. Actual results: Process uses 100% CPU until killed manually. Expected results: Process terminates without generating thumbnail (if it doesn't understand XPS) or does generate a thumbnail.
This bug is also reproducible with xpstopdf from libgxps-tools. I'm reassigning this to libgxps package. Regards Marek
I'm pretty sure this actually an issue with libarchive hanging reading the contents of the XPS file (which is really just a zip archive) but the actual root cause is that at least some versions of Windows produce invalid zip files when generating XPS output... In fact on F16 with libarchive 2.8.5 libgxps refuses to process this file with an error: Error creating XPS file: Source _rels/.rels not found in archive which is something I have seen before with Windows produces XPS files - unpacking them with unzip and repacking them with zip will fix it. F17 is using libarchive 3.0.3 and that seems to be hanging instead of reporting an error - once again repacking the file fixes it.
As I suspected, this appears to be an issue in libarchive so I am reassigning this to the libarchive component. I've written a test program which attempts to read the XPS file using libarchive in basically the same way that libgxps does and I'll attach it. The full contents of the archive, reported by unzip, are: Metadata/Job_PT.xml Metadata/MXDC_Empty_PT.xml Documents/1/Metadata/Page1_Thumbnail.JPG Documents/1/Pages/_rels/1.fpage.rels Documents/1/Pages/1.fpage Documents/1/Pages/_rels/2.fpage.rels Documents/1/Pages/2.fpage Documents/1/Resources/Fonts/5A3CF68E-185B-4FA2-AF24-3BD7184844F9.odttf Documents/1/_rels/FixedDocument.fdoc.rels Documents/1/FixedDocument.fdoc _rels/FixedDocumentSequence.fdseq.rels FixedDocumentSequence.fdseq _rels/.rels [Content_Types].xml My test program, run on F16 with libarchive 2.8.5, reports: Metadata/Job_PT.xml Metadata/MXDC_Empty_PT.xml Documents/1/Metadata/Page1_Thumbnail.JPG Error: Bad ZIP file and on F17 with libarchive 3.0.3, reports: Metadata/Job_PT.xml Metadata/MXDC_Empty_PT.xml Documents/1/Metadata/Page1_Thumbnail.JPG after which it hangs. I believe the zip file is indeed technically invalid - I did look into it before and it was something to do with the central directory not matching the headers properly or something. It would be good if libarchive could at least not hang though, and ideally it would read it as zip itself is apparently able to do.
Created attachment 582276 [details] Test program Test program - compile with "cc -Wall -g -o xpstest xpstest.c -larchive" and run with the test file from this bug in the same directory.
*** This bug has been marked as a duplicate of bug 844163 ***