Hi! Processing [1] with poppler results in a crash on 64 bit architectures. poppler/JPXStream.h declares 'cbW' to be unsigned (Guint), however, JPXStream.cc, readCodeBlockData() negates the value: diag += (coeff[-tileComp->cbW + 1].flags >> jpxCoeffSignificantB) & 1; On platforms with 64 bit pointers unsigned data types lead to an immensely large value of the resulting pointer, which causes a crash. Negating values should be done with signed data types only. This trivial patch fixes it: --- poppler-0.5.0/poppler/JPXStream.h 2005-09-07 04:34:40.000000000 +0200 +++ poppler-0.5.0.new/poppler/JPXStream.h 2006-01-19 23:22:00.000000000 +0100 @@ -211,7 +211,7 @@ //----- computed Guint x0, y0, x1, y1; // bounds of the tile-comp, in ref coords - Guint cbW; // code-block width + int cbW; // code-block width Guint cbH; // code-block height //----- image data Credit is due to Vladimir Nadvornik, who debugged this. Can you please pass this to xpdf upstream as well? Thanks! [1] http://www.fuerth.de/PortalData/1/Resources//lebeninfuerth/broschueren/veran05_2.pdf
I'm using an AMD 64 bits CPU here and don't have any problem with that pdf, could you test if you still have problem when using poppler CVS version? You could just use gtk-cairo-test/gtk-splash-test/qt-splash-test programs so you don't need to "mess" with your system libraries.
The link is broken. Does anyone have another example showing the problem?
This http://www.fuerth.de/Portaldata/1/Resources/LebenInFuerth/Dokumente/2004-2006/veran05_1.pdf document has a similar name, perhaps it reproduces the crash? Not under 64-bits ATM, can't check. Otherwise, could you check whether it would make sense to make the value an int instead of an unsigned one? We're carrying the patch in Debian, and I'd like it to be merged if it's useful :)
Created attachment 18409 [details] [review] Fix crash on 64-bits arches due to unsigned versus signed var I'm attaching the patch currently in use. I'm not able to reproduce the crash with the proposed file and evince loads the PDF against git's poppler with or without the patch (I tested with a local build and LD_LIBRARY_PATH=$PWD/poppler/.libs:$PWD/glib/.libs ./evince veran05_1.pdf; make sure you chrpath -d evince otherwise it will use system libs despite LD_LIBRARY_PATH). With and without the patch, the gtk-cairo-test fail with "Error loading veran05_1.pdf"; without the patch, gtk-splash-test opens a window with the displayed PDF.
Looking at the code, it seems now that everytime cbW is negated, it is explicitely casted to int: coeff[-(int)tileComp->cbW].flags Thus this bug should solved, and the patch not needed anymore for real?
I've been using poppler on a 64 bit machine since ages so yeah i think this can be closed
I agree, haven't had a problem in years.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.