Xpdf segfaults on start in libpoppler.so.7

[Peter Júnoš]

Xpdf segfaults in libpoppler7

Backtrace:
#0 0x00007ffff71fc666 in GooHash::hash(GooString*) ()
   from /usr/lib/libpoppler.so.7
#1 0x00007ffff71fc792 in GooHash::find(GooString*, int*) ()
   from /usr/lib/libpoppler.so.7
#2 0x00007ffff71fc80e in GooHash::lookup(GooString*) ()
   from /usr/lib/libpoppler.so.7
#3 0x00007ffff71a76e4 in GlobalParams::getResidentUnicodeMap(GooString*) ()
   from /usr/lib/libpoppler.so.7
#4 0x00007ffff71a7743 in GlobalParams::getUnicodeMap2(GooString*) ()
   from /usr/lib/libpoppler.so.7
#5 0x00007ffff71f63bd in TextPage::coalesce(int, int) ()
   from /usr/lib/libpoppler.so.7
#6 0x00007ffff71f8598 in TextOutputDev::endPage() ()
   from /usr/lib/libpoppler.so.7
#7 0x00007ffff7177cf3 in Gfx::~Gfx() () from /usr/lib/libpoppler.so.7
#8 0x00007ffff71c2f6e 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.7
#9 0x00007ffff71c3010 in Page::display(OutputDev*, double, double, int, int, int, int, Catalog*, int (*)(void*), void*, int (*)(Annot*, void*), void*) ()
   from /usr/lib/libpoppler.so.7
#10 0x0000000000414492 in ?? ()
#11 0x0000000000417511 in ?? ()
#12 0x0000000000419f68 in ?? ()
#13 0x000000000041257c in ?? ()
#14 0x00000000004262c8 in ?? ()
#15 0x000000000041838c in ?? ()
#16 0x0000000000427046 in ?? ()
#17 0x00007ffff65afd8e in __libc_start_main () from /lib/libc.so.6
#18 0x000000000040abf9 in ?? ()
#19 0x00007fffffffe288 in ?? ()
#20 0x000000000000001c in ?? ()
#21 0x0000000000000002 in ?? ()
#22 0x00007fffffffe565 in ?? ()
#23 0x00007fffffffe573 in ?? ()
#24 0x0000000000000000 in ?? ()

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: libpoppler7 0.14.3-0ubuntu1.1
ProcVersionSignature: Ubuntu 2.6.36-1.7-generic 2.6.36
Uname: Linux 2.6.36-1-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Sun Oct 31 20:38:19 2010
ProcEnviron:
 SHELL=/bin/bash
 LANG=sk_SK.UTF-8
SourcePackage: poppler

[Pedro Villavicencio (pedro)]

thanks for the report, could you attach the pdf causing the crash? thanks.

[Peter Júnoš (petoju)]

It crashes with every PDF I have tried. This makes xpdf unusable.

[Dennis Sheil (dennis-sheil)]

This poppler library works with this PDF with the Evince viewer. This poppler library works with this PDF with the Epdfview viewer. It only doesn't work with Xpdf. Also - Xpdf in Meerkat is not dependent on the poppler library by default. As Xpdf changed its behavior and broke, I am putting this in the xpdf queue. I have verified that Xpdf does break on every PDF I've tested on 11.03.

[Marcel Stimberg (marcelstimberg)]

I am also seeing this crash for every PDF I try, marking as confirmed.

[Marcel Stimberg (marcelstimberg)]

I'm attaching a more complete backtrace of the crash (triggered with Evolution’s quickref.pdf). I tried the xpdf version in Debian Squeeze which is also 3.02-11, it does not crash. The main difference between Squeeze and Natty is the poppler version, Debian Squeeze still uses 0.12.4-1.2 (libpoppler5), whereas Natty uses 0.14.5-0ubuntu2 (libpoppler7). It seems the crash arises from an incompatibility between xpdf and the newer poppler version.

[David Kastrup (dak)]

Crashes here as well. Backtrace:
#0 0x0048ea9d in GlobalParams::findFontFile(GooString*, char**) ()
   from /usr/lib/libpoppler.so.7
#1 0x00477516 in GfxFont::findExtFontFile() () from /usr/lib/libpoppler.so.7
#2 0x00477a5c in Gfx8BitFont::Gfx8BitFont(XRef*, char*, Ref, GooString*, GfxFontType, Dict*) () from /usr/lib/libpoppler.so.7
#3 0x0047aa70 in GfxFont::makeFont(XRef*, char*, Ref, Dict*) ()
   from /usr/lib/libpoppler.so.7
#4 0x0047b542 in GfxFontDict::GfxFontDict(XRef*, Ref*, Dict*) ()
   from /usr/lib/libpoppler.so.7
#5 0x00465bf9 in GfxResources::GfxResources(XRef*, Dict*, GfxResources*) ()
   from /usr/lib/libpoppler.so.7
#6 0x004753c4 in Gfx::Gfx(XRef*, OutputDev*, int, Dict*, Catalog*, double, double, PDFRectangle*, PDFRectangle*, int, int (*)(void*), void*) ()
   from /usr/lib/libpoppler.so.7
#7 0x004a612e in Page::createGfx(OutputDev*, double, double, int, int, int, int, int, int, int, int, Catalog*, int (*)(void*), void*, int (*)(Annot*, void*), void*) () from /usr/lib/libpoppler.so.7
#8 0x004a6327 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.7
#9 0x004a83fb 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.7
#10 0x0805a50e in ?? ()
#11 0x0805d89a in ?? ()
#12 0x08060437 in ?? ()
#13 0x0805862c in ?? ()
#14 0x0806e4f2 in ?? ()
#15 0x0805e7a9 in ?? ()
#16 0x0806f2e6 in ?? ()
#17 0x006cece7 in __libc_start_main () from /lib/libc.so.6
#18 0x08050621 in ?? ()

[Marcel Stimberg (marcelstimberg)]

This is actually not exactly the same crash I am seeing (but it is very likely closely related). It is the same crash that was present when xpdf was updated to poppler the last time (during Maverick development), back then it led to a complete revert of the changes. Maybe the old bug (Bug #611446) should be reopened?

[Michael Gilbert (michael-s-gilbert)]

i'm the debian maintainer. i've spent a day trying to track this issue down already without any luck. its probably originating in a dependency (like freetype). i'm not really sure why, and i don't have any more time to dig into this.

if someone wants to try mixing/matching dependencies using debian's packages, that could be useful in isolating the problem.

[Michael Gilbert (michael-s-gilbert)]

also, this may be caused by one of the compiler hardening features, which are on by default on ubuntu, but not debian. one could try compiling with -fno-stack-protector and other flags to see if there is any effect.

[Michael Gilbert (michael-s-gilbert)]

in the meantime, someone with appropriate permissions should increase the "importance" to release critical.

[yope (djander)]

xpdf also crashes for me on every single pdf file, so I tried re-building xpdf from source, but it won't compile.
Here is what I get (on natty as of today):

$ dpkg-buildpackage -rfakeroot -j8 -b
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions
dpkg-buildpackage: source package xpdf
dpkg-buildpackage: source version 3.02-12ubuntu1
dpkg-buildpackage: source changed by Bhavani Shankar <email address hidden>
dpkg-buildpackage: host architecture i386
 dpkg-source --before-build xpdf-3.02
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   debian/rules override_dh_clean
make[1]: Entering directory `/home/nfs/david/ubuntu-sources/xpdf-3.02'
dh_clean
rm -rf build
make[1]: Leaving directory `/home/nfs/david/ubuntu-sources/xpdf-3.02'
 debian/rules build
dh build
   dh_testdir
   # Skipping dh_auto_configure - empty override
   debian/rules override_dh_auto_build
make[1]: Entering directory `/home/nfs/david/ubuntu-sources/xpdf-3.02'
mkdir -p build
cp goo/parseargs.* xpdf/CoreOutputDev.* xpdf/GlobalParams.* build
cp xpdf/PDFCore.* xpdf/XPDFApp.* xpdf/XPDFCore.* xpdf/XPDFTree.* build
cp xpdf/XPDFTreeP.h xpdf/XPDFViewer.* xpdf/xpdf.cc build
# perform extensive goo rename (as required by poppler)
sed -i s/GString/GooString/g build/*
sed -i s/GMutex/GooMutex/g build/*
sed -i s/GHash/GooHash/g build/*
sed -i s/GList/GooList/g build/*
sed -i s/\<aconf\.h\>/\<poppler-config\.h\>/g build/*
cp xpdf/config.h xpdf/about-text.h xpdf/*.xbm xpdf/xpdfIcon.xpm build
g++ -g -O2 -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -c -o build/CoreOutputDev.o build/CoreOutputDev.cc
g++ -g -O2 -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -c -o build/GlobalParams.o build/GlobalParams.cc
build/GlobalParams.cc: In member function ‘void GlobalParams::parseNameToUnicode(GooList*, GooString*, int)’:
build/GlobalParams.cc:1147:72: warning: format ‘%s’ expects type ‘char*’, but argument 3 has type ‘GooString*’
g++ -g -O2 -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -c -o build/PDFCore.o build/PDFCore.cc
g++ -g -O2 -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -I/usr/include/poppler -I/usr/include/poppler/goo -I/usr/include/poppler/splash -Wno-write-strings -DHAVE_DIRENT_H -c -o build/XPDFApp.o bui...

[Michael Gilbert (michael-s-gilbert)]

poppler 0.16's api differs from 0.12, which xpdf is currently built for. i will fix this in debian when i find the time.

sorry for the rant, but this is exactly why ubuntu every ubuntu release turns out so buggy. blingy packages are pushed without consideration of their effects on the rest of the system.

so, anyway, someone needs to spend some time on the patch for this (i won't necessarily get to this any time soon), otherwise, the revert will need to be done for natty just like what was done for maverick.

mike

[Andreas Moog (ampelbein)]

fixed with 3.02-12ubuntu2

[kuh3h3 (kuh3h3)]

Andreas Moog // this bug is not fixed in xpdf 3.02-12ubuntu12.(with new libpoppler13 0.16.4-0ubuntu1). same segfault occures still.

^_^[/media/sdc1]$ gdb xpdf
GNU gdb (GDB) 7.2-
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/xpdf...(no debugging symbols found)...done.
(gdb) r ctags.pdf
Starting program: /usr/bin/xpdf ctags.pdf
Error: Couldn't open 'nameToUnicode' file '/usr/local/share/xpdf/cyrillic/Bulgarian.nameToUnicode'
***** MediaBox = ll:0,0 ur:595,842
***** CropBox = ll:0,0 ur:595,842
***** Rotate = 0

Program received signal SIGSEGV, Segmentation fault.
0xb7bfdd8d in GlobalParams::findFontFile(GooString*, char**) () from /usr/lib/libpoppler.so.13
(gdb) bt
#0 0xb7bfdd8d in GlobalParams::findFontFile(GooString*, char**) () from /usr/lib/libpoppler.so.13
#1 0xb7be56d6 in GfxFont::findExtFontFile() () from /usr/lib/libpoppler.so.13
#2 0xb7be5c6b in Gfx8BitFont::Gfx8BitFont(XRef*, char*, Ref, GooString*, GfxFontType, Dict*) () from /usr/lib/libpoppler.so.13
#3 0xb7be9634 in GfxFont::makeFont(XRef*, char*, Ref, Dict*) () from /usr/lib/libpoppler.so.13
#4 0xb7be9902 in GfxFontDict::GfxFontDict(XRef*, Ref*, Dict*) () from /usr/lib/libpoppler.so.13
#5 0xb7bd2ca7 in GfxResources::GfxResources(XRef*, Dict*, GfxResources*) () from /usr/lib/libpoppler.so.13
#6 0xb7be3481 in Gfx::Gfx(XRef*, OutputDev*, int, Dict*, Catalog*, double, double, PDFRectangle*, PDFRectangle*, int, bool (*)(void*), void*)
    () from /usr/lib/libpoppler.so.13
#7 0xb7c16cb0 in Page::createGfx(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/libpoppler.so.13
#8 0xb7c16ea4 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/libpoppler.so.13
#9 0xb7c1b80c in PDFDoc::displayPageSlice(OutputDev*, int, double, double, int, bool, bool, bool, int, int, int, int, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/libpoppler.so.13
#10 0x0805a998 in ?? ()
#11 0x0805de27 in ?? ()
#12 0x080609c9 in ?? ()
#13 0x080586db in ?? ()
#14 0x0806ed12 in ?? ()
#15 0x0805ed2a in ?? ()
#16 0x0806fb67 in ?? ()
#17 0xb790ae06 in __libc_start_main (main=0x806f250, argc=2, ubp_av=0xbfffe524, init=0x806fd10, fini=0x806fd70,
    rtld_fini=0xb7ff0a20 <_dl_fini>, stack_end=0xbfffe51c) at libc-start.c:226
#18 0x08050741 in ?? ()
(gdb) i r
eax 0x0 0
ecx 0xb7a3d3c0 -1214000192
edx 0x808a008 134782984
ebx 0xb7cc0ff4 -1211363340
esp 0xbfffd870 0xbfffd870
ebp 0xbfffd8b8 0xbfffd8b8
esi 0x810f7f8 1...

[Michael Gilbert (michael-s-gilbert)]

please revert to the pre-poppler version, which was also done for maverick. that is the only known solution at present. thanks.

[Shouri Chatterjee (shouri)]

The binary packaged xpdf still segfaults/crashes on every pdf file.

I successfully compiled a working xpdf on natty.

Here are the required dependencies aside from the regular automake etc packages (these were the maverick build-deps):
libfreetype6-dev libpaper-dev libt1-dev libx11-dev libxext-dev libxp-dev libxpm-dev libxt-dev x11proto-core-dev
I made sure that libpoppler-dev was not installed.

./configure can't find libfreetype. One has to:
cd /usr/include/ ; sudo ln -s freetype2/freetype

And then just getting the original source (apt-get source xpdf), and tar-gunzipping the original source, configuring, making and installing works fine.

[Michael Gilbert (michael-s-gilbert)]

> And then just getting the original source (apt-get source xpdf), and tar-gunzipping
> the original source, configuring, making and installing works fine.

that's not surprising. the upstream version (i.e. non-popplerized version) will work just fine, and that's the solution i've been pushing for (and the one that was done for maverick). but no one is stepping up to do it.

[Jim Rees (rees)]

Here's how I did it:

Get the source tarball and apply all patches from:
http://www.foolabs.com/xpdf/download.html

apt-get install libfreetype6-dev lesstif2-dev
./configure --with-t1-library=no --with-freetype2-includes=/usr/include/freetype2
make xpdf

If you do have libpoppler-dev installed you might need something like --without-poppler. I did not check this.

[Michael Gilbert (michael-s-gilbert)]

> apt-get install libfreetype6-dev lesstif2-dev
> ./configure --with-t1-library=no --with-freetype2-includes=/usr/include/freetype2
> make xpdf

this is a reasonable "workaround" (if you want to call it that). ideally someone will step up to actually fix the problem this time for the "o" release.

> If you do have libpoppler-dev installed you might need something like
> --without-poppler. I did not check this.

that won't make any difference.

[bcrowell (launchpadcrowell07)]

It seems inappropriate to me that the importance of this bug is set to "medium," since xpdf is broken and doesn't work at all.

[Chris Hobbs (cwlh)]

I agree with comment #21. This bug is preventing xpdf from running. I have just run into the problem having been tricked into "upgrading" to 11.04 and cannot understand why it would have a priority of anything other than "critical".

[Ursula Junque (ursinha)]

I created a xpdf package removing poppler support, following what @Jim Rees did and also applying other bugfixes the Ubuntu package has. It's waiting to be built in my PPA. Hope this helps while the bug isn't fixed properly in Ubuntu.

https://launchpad.net/~ursinha/+archive/ppa

[Silas S. Brown (ssb22)]

Ursula's .deb file fixes it for me. Thanks.

[Silas S. Brown (ssb22)]

Unfortunately there seems to be another bug in Ursula's package. I don't know if this bug also occurs in the official xpdf package because the official xpdf package crashes so I can't test any more. Ursula's package does not crash, but:

I was viewing a multi-page PDF file which I had generated using pdflatex, and I was pressing the N key on the keyboard to advance to the next page. This worked up to page 19, but after that, further presses of the N key no longer turn the pages. (They do increase the page number displayed at the bottom of the screen, but the actual page displayed does not change.)

I wondered if there was a problem with page 19 or 20 of my PDF, so I quit xpdf and tested again, but this time it got stuck on page 25. And on the 3rd test, it got stuck on page 5. And on the 4th test, it got stuck on page 9. It's obviously not dependent on a particular PDF page.

I wondered if it was because I was turning pages quite quickly, so I tried turning the pages more slowly, but I still experienced the problem.

However, I do not run into the problem if I click on the "next" button with the mouse instead of pressing the N key.

Once xpdf has become "stuck", it is sometimes possible to get it "unstuck" again by pressing P and N (previous and next) in various combinations, but this does not seem to be consistent.

I'm running xpdf from a terminal. No messages are printed in the terminal.

[Akkana Peck (akkzilla)]

epdfview also crashes on startup on every PDF file, on natty. Or should that be filed as a separate bug? I'm guessing it's the same problem, and there doesn't seem to be an epdfview-specific bug filed.

[Michael Gilbert (michael-s-gilbert)]

> epdfview also crashes on startup on every PDF file, on natty. Or
> should that be filed as a separate bug? I'm guessing it's the
> same problem, and there doesn't seem to be an epdfview-specific
> bug filed.

epdfview also uses poppler, and all evidence points poppler as the root cause at this point (probably a compiler option, and especially since the debian poppler package can be dropped in and it works), so i would say that this bug should be reassigned there.

can you attach a backtrace for the epdfview crash also? thanks.

[Michael Gilbert (michael-s-gilbert)]

actually, epdfview on natty seems to work just fine for me (tested a couple pdf files). your bug is probably a different issue altogether.

[Akkana Peck (akkzilla)]

I don't know if a stack trace from libs without symbols is useful, but here's epdfview:
#0 0xb775b706 in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0xb7f5777b in g_strdup () from /lib/i386-linux-gnu/libglib-2.0.so.0
#2 0x0011a56e in ?? ()
#3 0x0011fe93 in ?? ()
#4 0x00120684 in ?? ()
#5 0x0011c35d in ?? ()
#6 0x0011bf40 in ?? ()
#7 0xb7f602df in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#8 0xb7848e99 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#9 0xb77b173e in clone () from /lib/i386-linux-gnu/libc.so.6

It does work on some PDFs that xpdf crashes on, but it still crashes on others. http://www.ebparks.org/files/EBRPD_files/photoguides/1-EBRPD_Wildflowers.pdf crashes it repeatably.

[Michael Gilbert (michael-s-gilbert)]

> It does work on some PDFs that xpdf crashes on, but it still crashes on
> others. http://www.ebparks.org/files/EBRPD_files/photoguides/1-EBRPD_Wildflowers.pdf
> crashes it repeatably.

that's definately a different issue. you should submit a new bug against epdfview. you can get symbols for your backtrace by installing the libpoppler-dbg package.

[Vinh Nguyen (vinhdizzo)]

I just upgraded to Natty, and I got this error. The method of @Jim Rees worked for me. Uninstalled xpdf and compiled from source. Thanks!

[Akkana Peck (akkzilla)]

Split off the epdfview issue to bug 780911. I don't see debug symbols even with poppler-dbg, though. Compiling from source is working with xpdf, so maybe I'll try that with epdfview too.

[Alexander (lxandr)]

$ sudo apt-get install mupdf
now works for me as workaround. Or maybe even as replacement for xpdf/epdfview. Time will tell.

[rew (r-e-wolff)]

I THINK that xpdf worked for me for a while before it suddenly stopped working. But I can't be sure.

I then switched to epdfview as my PDF viewer. I was happy for a day or two....

Then epdfview started crashing just like xpdf....

The thing is... epdfview still displays SOME pdfs. For epdfview it depends on the PDF....

A PDF that epdfview displays correctly: http://www.bea.aero/docspa/2010/ec-v100329/pdf/ec-v100329.pdf

http://www.avagotech.com/docs/AV02-0629EN

redirects to a PDF that epdfview also crashes on. ..... For reference.. here is a stable link to the pdf that also crashes epdfview. http://prive.bitwizard.nl/AV02-0629EN+DS+HDSP-210x+02Dec2010.pdf

I would really like to work towards a solution that results in xpdf just working again.... (from the standard repositories...)

[rew (r-e-wolff)]

I wrote the above comment trying to argue that the epdfview bug was probably the same but forgot to make the point after the intro. However.....

epdfview however crashes in strdup (libc) and not in libpoppler.

[Switching to Thread 0x7fffec326700 (LWP 23313)]
0x00007ffff5a3a5d1 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0 0x00007ffff5a3a5d1 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7923062 in g_strdup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7fe6b85 in ?? ()
#3 0x00007ffff7febc40 in ?? ()
#4 0x00007ffff7fec2bb in ?? ()
#5 0x00007ffff7fe86c8 in ?? ()
#6 0x00007ffff7fe83f0 in ?? ()
#7 0x00007ffff792b3e4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007ffff5d52d8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007ffff5a9e04d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000000000 in ?? ()

[Marcel Stimberg (marcelstimberg)]

@rew: It has been stated in the previous comments that the epdfview issue is a different one. Please follow this bug report for the epdfview crashes: bug 783109

[michielhermes (michielhermes-colloids)]

Problems does seem to be with poppler. I installed the latest version from source (http://poppler.freedesktop.org/) and xpdf works again.

I do not know if it helps anyone but valgrind points at GlobalParams::findFontFile(GooString*, char**) (in /usr/lib/libpoppler.so.13.0.0) as the guilty party.

[Akkana Peck (akkzilla)]

Marcel: unfortunately bug 783109 isn't public (and my attempt to file a public one was duped to the private bug), so those of us experiencing problems with epdfview can't see that bug or add comments there. (Sorry for the spam, I'll shut up about epdfview now.) Thanks, Alexander, for the mupdf recommendation -- works great.

[Marcel Stimberg (marcelstimberg)]

@Akkana: Many thanks for the hint -- I accidentally left the bug at the private status :-/ It is public now, sorry for that.

[Marius B. Kotsbak (mariusko)]

@Chris, I was about to propose the increase of the importance of this bug, but it seems like the scale is not for the application (which would be "Critical"), but for all Ubuntu users. And since this packages is in "Universe", I guess it is not a core application, and thus applies for this description of "Medium": "A bug that has a severe impact on a non-core application.", but maybe also "Has a severe impact on a small portion of Ubuntu users (estimated)" in "High":

https://wiki.ubuntu.com/Bugs/Importance

[pranith (bobby-prani)]

Any update on this? I too am having a problem with xpdf not being able to read any pdfs.

[Bayle Shanks (bshanks)]

Thanks Ursula for your workaround.

[noah anderson (raoul-fleckman)]

Same problem xpdf crashed everytime and Ursula's solution fixed it. Thank you Ursula!

Natty has been a rough ride for some of us out here. xpdf is the 7th issue and there are still more.

[Anthonyt (v-tnthony-a)]

Thanks Ursula, that stopped the segmentation fault.

The /etc/xpdf/xpdfrc file does not seem to be read, maybe xpdf has been compiled to look elsewhere?
Changes to the psFile line have no effect. So I copied that file to ~/.xpdfrc and now the psFile is setting is being read.

[Horst Schirmeier (horst)]

Ursula's PPA works fine, thanks!

I cannot believe Ubuntu's xpdf is still *completely unusable* seven months after this bug report, even though there's a known fix, be it an unfavorable one or not.

[Rob Sargant (sargant)]

Initially posted a bug downstream on Linux Mint (#798671) until I saw this bug report. Kind of surprising that this is still broken.

Jim Rees' build commands from source (comment 19) worked great for me.

[Daniel Richard G. (skunk)]

As far as I can tell, the problem is due to the presence of two, seemingly-incompatible definitions of the GlobalParams class. One is in libpoppler (poppler/GlobalParams.cc), one is in the Xpdf source (xpdf/GlobalParams.cc). The diff between them is pretty extensive. If I attempt to link Xpdf without its own definition of the class, several methods are not found; if I link without poppler, a whole bunch of other things go missing.

The Poppler library itself is based on Xpdf, and while it is sensible to factor out the resulting redundant code from the latter, I think it is clear that more development work is needed to achieve that goal successfully.

[Michael Gilbert (michael-s-gilbert)]

> The Poppler library itself is based on Xpdf, and while it is sensible to factor out the
> resulting redundant code from the latter, I think it is clear that more development
> work is needed to achieve that goal successfully.

This conclusion is incorrect. The conversion works fine in Debian, but since Ubuntu makes changes without fully fleshing out potential side effects, things like this happen. This would not be a problem if they were using the Debian poppler version.

[Marcel Stimberg (marcelstimberg)]

> This would not be a problem if they were using the Debian poppler version.
Maybe it would be possible to ship libpoppler5 specifically for xpdf as a legacy version? Reverting to an old version of poppler in general is certainly not an option, e.g. epdfview and most importantly evince as the default pdf viewer work with the most recent version (and many would be unhappy if the annotation capabilities would be removed again ;)).

[Michael Gilbert (michael-s-gilbert)]

> Maybe it would be possible to ship libpoppler5 specifically for
> xpdf as a legacy version?

yes, that would certainly work, but someone would actually need to volunteer to do that.

> Reverting to an old version of poppler in general is certainly
> not an option, e.g. epdfview and most importantly evince as
> the default pdf viewer work with the most recent version (and
> many would be unhappy if the annotation capabilities would
> be removed again ;)).

my point was not to suggest going backwards, but to be more mindful when going forward.

[Ian! D. Allen (idallen)]

Same problem in natty with xpdf 3.02-12ubuntu2 and any PDF file. "evince" works fine.

$ gdb xpdf
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/xpdf...(no debugging symbols found)...done.
(gdb) run /tmp/gr.pdf
Starting program: /usr/bin/xpdf /tmp/gr.pdf

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71aeecb in GlobalParams::findFontFile(GooString*, char**) ()
   from /usr/local/lib/libpoppler.so.13
(gdb) bt
#0 0x00007ffff71aeecb in GlobalParams::findFontFile(GooString*, char**) ()
   from /usr/local/lib/libpoppler.so.13
#1 0x00007ffff7197b66 in GfxFont::findExtFontFile() ()
   from /usr/local/lib/libpoppler.so.13
#2 0x00007ffff71980bb in Gfx8BitFont::Gfx8BitFont(XRef*, char*, Ref, GooString*, GfxFontType, Dict*) () from /usr/local/lib/libpoppler.so.13
#3 0x00007ffff719b43c in GfxFont::makeFont(XRef*, char*, Ref, Dict*) ()
   from /usr/local/lib/libpoppler.so.13
#4 0x00007ffff719b6cf in GfxFontDict::GfxFontDict(XRef*, Ref*, Dict*) ()
   from /usr/local/lib/libpoppler.so.13
#5 0x00007ffff7183be2 in GfxResources::GfxResources(XRef*, Dict*, GfxResources*) () from /usr/local/lib/libpoppler.so.13
#6 0x00007ffff7195c2a in Gfx::Gfx(XRef*, OutputDev*, int, Dict*, Catalog*, double, double, PDFRectangle*, PDFRectangle*, int, bool (*)(void*), void*) ()
   from /usr/local/lib/libpoppler.so.13
#7 0x00007ffff71c6e87 in Page::createGfx(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/local/lib/libpoppler.so.13
#8 0x00007ffff71c710d in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/local/lib/libpoppler.so.13
#9 0x00000000004149bc in ?? ()
#10 0x0000000000417d71 in ?? ()
#11 0x000000000041a7ad in ?? ()
#12 0x0000000000412755 in ?? ()
#13 0x0000000000426e18 in ?? ()
#14 0x0000000000418bdd in ?? ()
#15 0x0000000000427b7c in ?? ()
#16 0x00007ffff65aceff in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#17 0x000000000040adf9 in ?? ()
#18 0x00007fffffffdf88 in ?? ()
#19 0x000000000000001c in ?? ()
#20 0x0000000000000002 in ?? ()
#21 0x00007fffffffe439 in ?? ()
#22 0x00007fffffffe447 in ?? ()
#23 0x0000000000000000 in ?? ()
(gdb) quit

[G.M. (sexxxenator)]

"Ursula's .deb file fixes it for me. Thanks."

Yes, Ursula's .deb file fixes the crashing problem for me too.

However and unfortunately, it occurs frenquently that what gets out of the printer when I try to print a pdf file with Xpdf is a sheet with an error message printed in red. This does never occur when printing with Evince.

The last error occurred when printing the attached document (a pdfnup'ed version of the English Wikipedia page about "Dynamic Programming"). It said (abbrigged, I don't have time to copy the whole message from the paper sheet by hand...) :

ERROR: ioerror (COMMAND TYPE: operatortype)
OFFENDING COMMAND: image "image"

OPERAND STACK: (1 total entries)

[...]

DICTIONARY STACK: (16 total entries)
  ===top of stack===
  <unknown>
   [...] [repeated 12 times]
   <unknown>
   xpdf
   userdict
   globaldict
   systemdict

EXECUTION STACK: (13 total entries)
[...]

[Sergio Cuellar Valdes (herrsergio)]

Same problem.

************************
ProblemType: Bug
Architecture: amd64
Date: Mon Jul 25 20:23:42 2011
Dependencies:
 coreutils 8.5-1ubuntu6 [modified: bin/cat bin/chgrp bin/chmod bin/chown bin/cp bin/date bin/dd bin/df bin/dir bin/echo bin/false bin/ln bin/ls bin/mkdir bin/mknod bin/mktemp bin/mv bin/pwd bin/readlink bin/rm bin/rmdir bin/sleep bin/stty bin/sync bin/touch bin/true bin/uname bin/vdir usr/bin/[ usr/bin/arch usr/bin/base64 usr/bin/basename usr/bin/chcon usr/bin/cksum usr/bin/comm usr/bin/csplit usr/bin/cut usr/bin/dircolors usr/bin/dirname usr/bin/du usr/bin/env usr/bin/expand usr/bin/expr usr/bin/factor usr/bin/fmt usr/bin/fold usr/bin/groups usr/bin/head usr/bin/hostid usr/bin/id usr/bin/install usr/bin/join usr/bin/link usr/bin/logname usr/bin/md5sum usr/bin/mkfifo usr/bin/nice usr/bin/nl usr/bin/nohup usr/bin/nproc usr/bin/od usr/bin/paste usr/bin/pathchk usr/bin/pinky usr/bin/pr usr/bin/printenv usr/bin/printf usr/bin/ptx usr/bin/runcon usr/bin/seq usr/bin/sha1sum usr/bin/sha224sum usr/bin/sha256sum usr/bin/sha384sum usr/bin/sha512sum usr/bin/shred usr/bin/shuf usr/bin/sort usr/bin/split usr/bin/stat usr/bin/stdbuf usr/bin/sum usr/bin/tac usr/bin/tail usr/bin/tee usr/bin/test usr/bin/timeout usr/bin/tr usr/bin/truncate usr/bin/tsort usr/bin/tty usr/bin/unexpand usr/bin/uniq usr/bin/unlink usr/bin/users usr/bin/wc usr/bin/who usr/bin/whoami usr/bin/yes usr/sbin/chroot]
 debconf 1.5.36ubuntu4
 debconf-i18n 1.5.36ubuntu4
 debianutils 3.4.3ubuntu1 [modified: bin/run-parts bin/tempfile]
 dpkg 1.16.0~ubuntu7 [modified: sbin/start-stop-daemon usr/bin/dpkg usr/bin/dpkg-deb usr/bin/dpkg-divert usr/bin/dpkg-query usr/bin/dpkg-split usr/bin/dpkg-statoverride usr/bin/dpkg-trigger usr/bin/update-alternatives usr/sbin/install-info]
 fontconfig-config 2.8.0-2.1ubuntu3
 gcc-4.5-base 4.5.2-8ubuntu4
 lesstif2 1:0.95.2-1 [modified: usr/lib/libXm.so.2.0.1]
 libacl1 2.2.49-4ubuntu2
 libattr1 1:2.4.44-2ubuntu3
 libbz2-1.0 1.0.5-6ubuntu1 [modified: lib/libbz2.so.1.0.4]
 libc-bin 2.13-0ubuntu13 [modified: usr/bin/getconf usr/bin/getent usr/bin/iconv usr/bin/locale usr/bin/localedef usr/bin/rpcinfo usr/bin/zdump usr/lib/pt_chown usr/sbin/iconvconfig usr/sbin/zic]
 libc6 2.13-0ubuntu13
 libdb4.8 4.8.30-5ubuntu2
 libexpat1 2.0.1-7ubuntu3
 libfontconfig1 2.8.0-2.1ubuntu3
 libfreetype6 2.4.4-1ubuntu2
 libgcc1 1:4.5.2-8ubuntu4
 libice6 2:1.0.7-1ubuntu1
 libjpeg62 6b1-1ubuntu1
 liblcms1 1.18.dfsg-1.2ubuntu1 [modified: usr/lib/liblcms.so.1.0.18]
 liblocale-gettext-perl 1.05-6
 liblzma2 5.0.0-2 [modified: usr/lib/liblzma.so.2.0.0]
 libncurses5 5.7+20101128-1 [modified: lib/libncurses.so.5.7 usr/lib/libform.so.5.7 usr/lib/libmenu.so.5.7 usr/lib/libpanel.so.5.7 usr/lib/libtic.so.5.7]
 libpam-modules 1.1.2-2ubuntu8.3
 libpam-modules-bin 1.1.2-2ubuntu8.3 [modified: sbin/mkhomedir_helper sbin/pam_tally sbin/pam_tally2]
 libpam0g 1.1.2-2ubuntu8.3
 libpng12-0 1.2.44-1ubuntu3
 libpoppler13 0.16.4-0ubuntu1.1 [modified: usr/lib/libpoppler.so.13.0.0]
 libselinux1 2.0.96-1ubuntu2
 libsm6 2:1.2.0-1ubuntu1
 libstdc++6 4.5.2-8ubuntu4
 libtext-charwidth-perl 0.04-6
 libtext-iconv-perl 1.7-2
 libtext-wrapi18n-perl 0.06-7
 libuuid1 2.17.2-9.1ubuntu4
 libx11-6 2:1.4.2-...

[Kierun (ubuntu-kierun)]

@Michael Gilbert: I just did a apt-get update && apt-get install xpdf and the resulting xpdf still core dumps. Am I missing something?

$ xpdf fu.pdf
Segmentation fault (core dumped)
$ gdb xpdf
[...]
(gdb) run
Starting program: /usr/bin/xpdf

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71aeecb in GlobalParams::findFontFile(GooString*, char**) ()
   from /usr/lib/libpoppler.so.13

[Marcel Stimberg (marcelstimberg)]

@Kierun: The status "Fix Released" means it is fixed in the *current development release*[1], i.e. in Ubuntu Oneiric. If you find it still crashes in Oneiric, feel free to reset the status to "New". For a fix in Natty, you (or someone else) has to follow the SRU process[2].

[1] https://wiki.ubuntu.com/Bugs/Status
[2] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

[UWP (uwp)]

This is a bit strange to me. The stable version doesn't run, it segfaults. Lots of people saying "bugbugbug". A fix comes. And now we have the strange situation that the bug will not be fixed for the environment it has been found? I don't want to update to oneiric now and I thought: when it's fixed, it must go the way into the stable release at first. You cannot destroy anything because at this time it doesn't run at all. I don't understand why the process is that bureaucratic and strange. It will bring me to the state of not telling about bugs because it won't give me anything back. I guess this is not the way it should work, don't you think? Or are we just too impatient and in 2 weeks it's included in the standard natty stream?

[Marcel Stimberg (marcelstimberg)]

@UWP: That might be strange but it is the standard procedure in every Linux distribution. Only the most recent development version (in this case, Oneiric) has the most recent upstream version and can benefit from bug fixes in that distribution. The version in natty cannot be simply updated to the most recent version as that could introduce new bugs (granted, for a program in an unusable state such at xpdf at the moment, this is not such a big problem). Instead, someone has to identify the changes made upstream that specifically fix the issue at hand, this then has to be applied to the version in Natty, go through review and be uploaded. This process can be quite fast (especially in this case, where regressions are not really a problem), but someone has to do it.
I did not check whether the upstream (which is in this case Debian) changes are easy to backport yet, but I might do later and initiate the SRU process. Note that xpdf is in the universe repository [1] and therefore "not officially supported software", meaning volunteers from the community have to step up.

I do admit though that the launchpad bug status can be misleading, someone should open a bug task for Natty (unfortunately, only members of BugControl can do that) which would clearly show that the issue still exists in Natty.

[1] https://help.ubuntu.com/community/Repositories/Ubuntu

[Ralf Hildebrandt (ralf-hildebrandt)]

* Marcel Stimberg <email address hidden>:

> I did not check whether the upstream (which is in this case Debian)
> changes are easy to backport yet, but I might do later and initiate the
> SRU process.

I guess we all would appreciate this.

> Note that xpdf is in the universe repository [1] and therefore "not
> officially supported software", meaning volunteers from the community
> have to step up.

I for my part appreciate your effort - we all love xpdf!

> I do admit though that the launchpad bug status can be misleading,

Oh yes!

[UWP (uwp)]

@Marcel: Ok, I understand that the SRU process is needed. My problem is that I (and I guess lots of other people here) don't have the background to do it (patches? I'd like to have the binary package...). I'd appreciate it if you do this for us. And there wouldn't be any other way? Maybe some kind of extra repository of recently fixed bugs, which I just have to add to /etc/apt/sources.list? For me it's kind of hard to see what I can do now: maybe there's a source-package I can use? Maybe we can write an email to someone who's able to open such a bug task for natty? I'm really feeling lost here.

Anyway, thank you for clearing things up!

[Ralf Hildebrandt (ralf-hildebrandt)]

I tried the version in oneiric, and indeed, I can display PDFs again!

[Marcel Stimberg (marcelstimberg)]

Here is a quick update on what I found out: The xpdf changes in debian (that are also in oneiric) are not responsible for fixing the issue. Instead, some change in the poppler library (which was also updated in oneiric) fixes the crash. I'll try to find out what change exactly is necessary. In the meantime, could someone experiencing the issue try to install the libpoppler13 library from oneiric (http://packages.ubuntu.com/oneiric/libpoppler13 -- download links at the bottom) and confirm that this fixes the xpdf crash (please do that only if you also know how you could revert such a manual installation)?

[Ralf Hildebrandt (ralf-hildebrandt)]

% sudo dpkg -i libpoppler13_0.16.7-2ubuntu1_amd64.deb

makes xpdf work for me. Yay!

[UWP (uwp)]

And to be precise: it can be used with the original xpdf-packages from ubuntu. The SEGV-bug was only in the poppler-libs. I also tried compiling from source and it also worked. This means: for those of you who need xpdf we now have 2 workarounds: install libpoppler by hand, either from the oneiric-URL or by taking the sources from there and doing a dpkg-buildpackage:

cd /tmp
wget http://archive.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.16.7.orig.tar.gz
wget http://archive.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.16.7-2ubuntu1.debian.tar.gz
tar zxf poppler_0.16.7.orig.tar.gz
cd poppler-0.16.7
tar zxf ../poppler_0.16.7-2ubuntu1.debian.tar.gz
dpkg-buildpackage
(this process will tell you, what else you might need, libs, devs whatever)
afterwards:
cd ..
sudo dpkg -i libpoppler13_0.16.7-2ubuntu1_amd64.deb libpoppler-cpp0_0.16.7-2ubuntu1_amd64.deb libpoppler-cpp-dev_0.16.7-2ubuntu1_amd64.deb libpoppler-dev_0.16.7-2ubuntu1_amd64.deb libpoppler-glib6_0.16.7-2ubuntu1_amd64.deb libpoppler-glib-dev_0.16.7-2ubuntu1_amd64.deb libpoppler-qt4-3_0.16.7-2ubuntu1_amd64.deb libpoppler-qt4-dev_0.16.7-2ubuntu1_amd64.deb poppler-dbg_0.16.7-2ubuntu1_amd64.deb poppler-utils_0.16.7-2ubuntu1_amd64.deb

This might be a bit more than you need but at least, afterwards xpdf runs quite fine!

[Vinh Nguyen (vinhdizzo)]

@UWP Thank you for sharing your precise instructions. I used to use Jim Reeses's solution (compiling xpdf from source) and the segmentation fault went away. However, on a few of the pdf files that I view, I get the error "Bogus memory allocation size". I had to resort to evince or adobe reader to view these files. I installed libpoppler per your instructions re-installed ubuntu's xpdf, and removed my compiled xpdf, and the files with the bogus memory issue can now be viewed with xpdf. Life is good again....

[Daniel Richard G. (skunk)]

Confirmed here too. The libpoppler13 version 0.16.7-2ubuntu1 package (current version in Oneiric) installs cleanly on Natty, and allows Xpdf to run without segfaults.

[Jens Maus (jens.maus)]

Can confirm the fix with installing libpoppler13 v0.16.7-2ubuntu1 as well. However, I still propose to backport that fix to 11.04 (natty) as there the xpdf installation is still broken and no update has been released for it so far and oneiric isn't out yet and perhaps not all people are going to switch to it immediately!

[Kierun (ubuntu-kierun)]

@Marcel Stimberg, thanks. This does indeed solve it for me as well.

A back port to Natty would indeed be a good thing (TM).

[Felix (felixfontein)]

When will there be a fix for Ubuntu 11.04? This bug has been terribly annoying over the past half a year.

[Marius B. Kotsbak (mariusko)]

I guess you should use the LTS if you don't want random problems with non core applications. Or install Oneiric beta. Or do as the rest of us, use another (core) application like evince/okular.

[Felix (felixfontein)]

So far I was using evince and Acrobat Reader, but both don't allow me to open a PDF file more than once at the same time. But thanks for mentioning okular, I've tried that one and it does this.

[sergioroa (s-roa)]

One of the sources mentioned in comment #63 now has to be changed to:
http://archive.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.16.7-2ubuntu2.debian.tar.gz

Then, the installation procedure is:

sudo dpkg -i libpoppler13_0.16.7-2ubuntu2_amd64.deb libpoppler-cpp0_0.16.7-2ubuntu2_amd64.deb libpoppler-cpp-dev_0.16.7-2ubuntu2_amd64.deb libpoppler-dev_0.16.7-2ubuntu2_amd64.deb libpoppler-glib6_0.16.7-2ubuntu2_amd64.deb libpoppler-glib-dev_0.16.7-2ubuntu2_amd64.deb libpoppler-qt4-3_0.16.7-2ubuntu2_amd64.deb libpoppler-qt4-dev_0.16.7-2ubuntu2_amd64.deb poppler-dbg_0.16.7-2ubuntu2_amd64.deb poppler-utils_0.16.7-2ubuntu2_amd64.deb

[MMlosh (mmlosh)]

This bug is probably back in ubuntu Precise.. only with libpoppler19

[Marius B. Kotsbak (mariusko)]

Xpdf works for me in Precise. Please install all updates and if it still does not run, open a new bug report using "ubuntu-bug" command.

[MMlosh (mmlosh)]

Updated again, still not running.
xpdf 3.02-21build1, libpoppler19 0.18.4-1ubuntu2
(crash message = ***** MediaBox = ll:0,0 ur:841.89,595.28 ***** CropBox = ll:0,0 ur:841.89,595.28 ***** Rotate = 0 Segmentation fault )
su

I remember it worked with oneiric's libpoppler.
I will fill another bug in the afternoon, can you please suggest proper title/tags?

[Marius B. Kotsbak (mariusko)]

I reproduce it when I add a PDF file argument, but when Precise wants to file a bug report it tells me it has already been reported (private bug).

[MMlosh (mmlosh)]

So there is really nothing more I can do for now? ok

[Michael Gilbert (michael-s-gilbert)]

i took a minute to look at this, and yes, once again, there is a segfault on all pdf's :( the backtrace is different, so this really is a different issue...but anyway the discussion is here now, so on to the solution...

to fix this, you can simply install the known working oneiric xpdf and poppler packages:

$ wget http://us.archive.ubuntu.com/ubuntu/pool/universe/x/xpdf/xpdf_3.02-21_i386.deb
$ wget http://us.archive.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler13_0.16.7-2ubuntu2_i386.deb
$ sudo dpkg -i xpdf_*.deb libpoppler13_*.deb

[Marcel Stimberg (marcelstimberg)]

Just for the record: the (now public) bug report for this issue in Ubuntu 12.04 is bug #943195 -- discussion should continue there.