Hi -
I encounter this bug with some frequency as I use continuous view as a
default setting in my .xpdfrc ("continuousView yes"). It reproduces
readily for me with a 32-bit x86 3.02-11 xpdf, using the PLRM.pdf.
I have been able to trigger the same failure mode outside of continuous
mode, but it is much less common. I am using 32-bit x86 3.02-11.
Anyways, it is indeed the same bug as #464753.
I have independently come up with a patch (which is at the bottom of this
email), which happens to be exactly the same as the one suggested in bug
#464753:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;filename=fix-464753.dpatch;att=1;bug=464753
I built a debug version of xpdf but did not bother to build a debug
version of libpopper, so my tracing is somewhat limited...
Anyways, here is the analysis... PDFCore::needTile() is responsible for
creating and initializing a XPDFCoreTile, but inheritance is such that it
is only aware that it is initializing a PDFCoreTile, which does not have
the "image" member, so it does not initialize that. It calls into
PDFDoc::displayPageSlice(), which is within libpopper and thus basically
a black box to me. However, in the typical case it eventually gets into
XPDFCore::updateTileData() which fills in the XPDFCoreTile::image. The
call stack to updateTileData() looks like:
#0 XPDFCore::updateTileData (this=0x80d0d78, tileA=0x80ed338, xSrc=0, ySrc=0,
width=383, height=495, composited=0) at build/XPDFCore.cc:1170
#1 0x08063d3a in PDFCore::clippedRedrawRect (this=0x80d0d78, tile=0x80ed338,
xSrc=0, ySrc=0, xDest=191, yDest=0, width=383, height=495, xClip=0,
yClip=0, wClip=765, hClip=668, needUpdate=1, composited=0)
at build/PDFCore.cc:2051
#2 0x080636bb in PDFCore::redrawCbk (data=0x80d0d78, x0=0, y0=0, x1=382,
y1=494, composited=0) at build/PDFCore.cc:1952
#3 0x080514fd in CoreOutputDev::dump (this=0x80d13b8)
at build/CoreOutputDev.cc:53
#4 0xf7d5f695 in Gfx::go(int) () from /usr/lib/libpoppler.so.5
#5 0xf7d5fd69 in Gfx::display(Object*, int) () from /usr/lib/libpoppler.so.5
#6 0xf7dacce0 in Page::displaySlice(OutputDev*, double, double, int, int, int,
int, int, int, int, int, Catalog*, int (*)(void*), void*, int (*)(Annot*,
void*), void*) () from /usr/lib/libpoppler.so.5
#7 0xf7db09c7 in PDFDoc::displayPageSlice(OutputDev*, int, double, double,
int, int, int, int, int, int, int, int, int (*)(void*), void*, int (*)(Annot*,
void*), void*) () from /usr/lib/libpoppler.so.5
#8 0x0805f300 in PDFCore::needTile (this=0x80d0d78, page=0x80d1a40, x=0, y=0)
at build/PDFCore.cc:843
In the case where it fails, Gfx::go() is called several times but
CoreOutputDev::dump() is never called. Why this is, I couldn't tell you,
though I have a theory that Page::displaySlice() gets obj.isNull() as
true for the important part... The end result is that the
XPDFCoreTile::image is NULL for this tile and the XPutImage() encounters
a SIGSEGV.
Anyways, it only seems to happen for blank pages, so as near as I can
tell the patch is correct. At the very least, the patch is not wrong --
it is never advantageous to dereference NULL. At the worst, this patch
will replace a SIGSEGV bug with a failure to display content bug. But
empirically, it only fails to display blank pages.
So please now apply this patch which has been available to you for some
time.
Thanks,
- Greg
--- xpdf/XPDFCore.cc 2010/10/12 21:17:02
+++ xpdf/XPDFCore.cc 2010/10/12 21:17:11
@@ -1348,7 +1348,7 @@
}
// draw the document
- if (tile) {
+ if (tile && tile->image) {
XPutImage(display, drawAreaWin, drawAreaGC, tile->image,
xSrc, ySrc, xDest, yDest, width, height);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
