xpdf.real crashed with SIGSEGV in GooHash::hash()

StacktraceTop:
 GooHash::hash(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::find(GooString*, int*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::lookup(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getResidentUnicodeMap(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getUnicodeMap2(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19

Status changed to 'Confirmed' because the bug affects multiple users.

Do we really have to have this bug every two releases again? IIRC, last time round was due to some poppler library upgrade, and was not fixed for the entire life time of the release. I recommend looking in the xpdf bug history to check how this got fixed last time. It is likely that the fix might be related.

How is a crash at startup priority "Medium"? It does not get any worse than that, does it?

The last time the bug stayed around for a year without being catered for it was called bug #669211. It is rather obviously the same bug with the same symptoms.

David: it is not a core application (probably in Universe). You can use Evince (Gnome/Unity) or Okular (Kubuntu).

Evince does not interact with LilyPond's point-and-click functionality. It also does not work with AUCTeX's source special support. The same for Okular.

The previous package of xpdf works. It is not clear to me what the point in replacing it with a version that crashes when viewing any file is supposed to be.

@David: No one claimed that xpdf is useless -- it is just "only" community supported, i.e. in universe and not in main. The status has been set to "Medium" automatically by apport, as it does for all crash reports. The correct status would actually be "High" ("Prevents the application or any dependencies from functioning correctly at all ") but only someone with BugControl privileges can change the importance. However, I doubt this will make this problem go away any sooner... Note that xpdf has *not* been replaced with a new version, the poppler library has changed and simply rebuilding xpdf was not enough, obviously. It is worth looking at the Debian package for xpdf in debian experimental (maintained by Michael Gilbert who commented on some of the crash reports here in launchpad) that *seems* to be working with the same poppler version that Ubuntu is using.

It is not the same bug. Last time xpdf was crashing even before any window came up. This time xpdf is launching the window, rendering the first page of the pdf file (you can see it for a jiffy), and then crashing out.

So now that we have waited for over a month without the bug even being assigned - does this mean that xpdf will not be fixed through the lifetime of precise?

I cannot believe comment #9. When I try to view this document http://www.hems.de/Allgemeinbildung/FormelsammlungPhysikMechanik.pdf , evince only shows garbage on the screen. This bug got never fixed. That's why I prefer xpdf.

It is displayed correctly in my evince 3.4.0. Which version do you use? Are you sure you have the required fonts installed (is package "ttf-mscorefonts-installer" installed?) ?

On my Ubuntu 12.04 install, downgrading libpoppler19 from "0.18.4-1ubuntu2" to "0.18.4-1" (the latter available from Debian experimental) resolved this crash for me.

I can confirm that downgrading to 0.18.4-1 from debian experimental works.Ubuntu versions 0.18.4-1ubuntu2 and 0.18.4-1ubuntu1 both caused xpdf to crash. I'm on 12.04 64bit.

For the lazy:
http://packages.debian.org/experimental/amd64/libpoppler19/download

The debian package also seems to work for me. I had to install libopenjpeg2 manually, though.
BTW, xpdf is essential, for example, if you want to use whizzytex (http://cristal.inria.fr/whizzytex/), since AFAIK it does not support evince.

Strange: Using the original .deb from Debian prevents the crash, but taking the Debian sources, building a package from them in Ubuntu 12.04 and installing the package, does not.

and I confirm that installing from debian experimental libpoppler19_0.18.4-1_i386 works also for 32 bit

I guess, I have an explanation for the bug and why it is emerging again now and then.

...
The memory location 0x80(%rdi) is written only once, that revealed that the libpoppler GlobalParams class constructor did not write it. In fact, the constructor is never called. Instead of that, the xpdf program brings an own and divergent version of the GlobalParams class, handling that over to libpoppler. Comparing the different definitions (xpdf/GlobalParams.h and poppler/GlobalParams.h) reveals, that xpdf class definition will copy boolean configuration values to that location, used by libpoppler to store textEncoding.
...

See http://www.halfdog.net/Security/2012/XpdfCrashAnalysisUbuntuPrecise/ for full analysis.

Sorry for the dump question: How do I downgrade libpoppler19? Downloading the deb file file gets me into "Error: A later version is already installed" from software center or gdebi. What would be the command line equivalent to install it?

Just run
sudo dpkg -i libpoppler19_0.18.4-1_amd64.deb
(or whatever .deb file you downloaded).

The debian-package downgrade worked for me, too.

Thanks! I have xpdf working again :-)

The downgrade worked in that xpdf does not crash any longer (I did have to install libopenjpeg2 as #18 points out). However, xpdf -z 50 foo.pdf does not seem to work: I get an initial zoom of 125%, no matter what I specify for the zoom value. Can somebody try to replicate this problem?

Another confirmation that the Debian 0.18.4-1 package (i386) fixes this problem for me.

Also, ISTM that bugs 992486 and 995829 are probably duplicates of this bug, although the reported symptoms differ slightly. Don't know who gets to make that call, though. There are a ton of other 'xpdf crashes on startup' bugs open too, although some are for previous versions.

Debian bug 658264 has a discussion on this, and a propsed patch. I don't know if its been applied to the debian tree yet, but it seems to work.

Here is a link to the patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;mbox=yes;bug=658264
(wget it and apply!)

Here's another pdf file that reliably produces this crash for me on x86 Precise: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/iil.pdf (md5sum 4ee8af8ada7b8ca1303211a08b66bdef).

Confirming the bug with Ubuntu Precise amd64.

After trying various fixes posted on the web and totally wrecking my package system (mixing in i386 packages by mistake), for me finally worked in Ubuntu Precise _64bit_ version:

$ apt-get purge libpoppler19*

$ wget http://us.archive.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ wget http://us.archive.ubuntu.com/ubuntu/pool/universe/x/xpdf/xpdf_3.02-21_amd64.deb

$ sudo dpkg -i libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ sudo dpkg -i xpdf_3.02-21_amd64.deb

Now there's a little catch to this because with daily ubuntu updates, the package manager will try to re-build xpdf against libpoppler19, which breaks xpdf again. To prevent this, put the xpdf package on hold via

$ echo "xpdf hold" | sudo dpkg --set-selections

This can be undone with

$ echo "xpdf install" | sudo dpkg --set-selections

To check the status:

$ dpkg --get-selections | grep xpdf

Done! ;-)

Good luck all!
.roots

Following comment #27 I rebuilt the precise source package using the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;mbox=yes;bug=658264 and the crashes stopped for me.

I hope a fix can make it into 12.04.1 -- it would be frustrating if the LTS Ubuntu boxes that will be around for years all have a completely broken xpdf.

I wish a clarification about comment #29
In my distro
 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ apt-get purge libpoppler19*

implies
The following packages will be REMOVED:
  bluez-cups* cups* cups-filters* dvipng* evince* gimp* hplip*
  indicator-printers* kile* latex-beamer* latex-xcolor* libevince3-3*
  libpoppler-glib8* libpoppler19* luatex* pgf* poppler-utils*
  printer-driver-gutenprint* printer-driver-hpcups* prosper* texlive*
  texlive-base* texlive-binaries* texlive-extra-utils* texlive-font-utils*
  texlive-fonts-recommended* texlive-generic-recommended* texlive-latex-base*
  texlive-latex-extra* texlive-latex-recommended* texlive-luatex*
  texlive-pictures* texlive-pstricks* tipa* xpdf*

is this rebuilt upon continuing with the reinstall?
$ wget http://us.archive.ubuntu.com/ubuntu/pool/universe/x/xpdf/xpdf_3.02-21_amd64.deb

$ sudo dpkg -i libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ sudo dpkg -i xpdf_3.02-21_amd64.deb

@ Comment 31:

Erm yes, isn't it a little weird that the application the fixed xpdf is intended for (tex) needs to be deinstalled to allow fixing?! ;-)

I have to admit this is a little drawback of the described method. The packages got deinstalled and needed to be reinstalled separately. However, I preferred reintalling cups and tex over not being able to use xpdf at all... ;-)

Cheers,
.roots

The same problem in Xubuntu 12.10 alpha-1.

same problem with Ubuntu 12.10 64-bit Kernel Linux 3.5.0-4-generic

alas, on an attempt to reinstall they still "require" libpoppler19

> The following extra packages will be installed:
> libpoppler19

I have attempted most of the proposed "solutions" for this problem. Patching 3.02, using nopopler binary, using the oneiric
package, etc, etc.

None (no not one) of them give a stable xpdf on my
Ubuntu Precise 64-bit system: 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Even though some of the proposed fixes prevent the crashes on startup. They none of them avoid a crash when repeatedly switching from full-screen/presentation to windowed by repeatedly hitting Alt-f.

I have instead compiled xpdf 3.03 (not 3.02) from source as follows:
Remove all xpdf packages.
sudo apt-get install lesstif2-dev

wget ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.03.tar.gz
tar xzf xpdf-3.03.tar.gz
cd xpdf-3.03
wget http://silas.psfc.mit.edu/xpdf3.03Viewer.patch
patch < xpdf3.03Viewer.patch
./configure --with-freetype2-library=/usr/lib/x86_64-linux-gnu/ --with-freetype2-includes=/usr/include/freetype2
make
sudo make install

This gives a robust xpdf. The patch is a trivial cast correction. I found it necessary to correct a compile failure.

Good luck to you all. Ian Hutchinson

I do not reproduce this problem in Quantal versions of xpdf and poppler.

Compiling from xpdf-3.03 source as Ian suggests (comment #36) works for me also. Thanks! :-)

I had to cd into the xpdf subdirectory of xpdf-3.03 when applying the patch.

For my 32-bit machine I changed the ./configure line to:

./configure --with-freetype2-library=/usr/lib/i386-linux-gnu/ --with-freetype2-includes=/usr/include/freetype2

I can reproduce this in quantal:

wget -nd http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/iil.pdf
xpdf iil.pdf

xpdf displays the first page for quite a while, then crashes.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77716c0 in GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
(gdb) bt
#0 0x00007ffff77716c0 in GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#1 0x00007ffff7771712 in GooHash::find(GooString*, int*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#2 0x00007ffff77718ce in GooHash::lookup(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#3 0x00007ffff771d8d4 in GlobalParams::getResidentUnicodeMap(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#4 0x00007ffff771f7a3 in GlobalParams::getUnicodeMap2(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#5 0x00007ffff7767d6a in TextPage::coalesce(bool, double, bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#6 0x00007ffff776cf42 in TextOutputDev::endPage() () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#7 0x00007ffff76f87ec in Gfx::~Gfx() () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#8 0x00007ffff77392a5 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#9 0x00007ffff773934e in Page::display(OutputDev*, double, double, int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#10 0x0000555555588fb2 in ?? ()
#11 0x000055555558c560 in ?? ()
#12 0x000055555558ef86 in ?? ()
#13 0x0000555555586bd2 in ?? ()
#14 0x000055555559c892 in ?? ()
#15 0x000055555558d453 in ?? ()
#16 0x000055555557e11a in main ()

Back to circumventing the problem - from the current repositories, Debian/squeeze got xpdf 3.02-12+squeeze1 with libpoppler5 - this works.

Also, evince is good only for copypasting text. It got antialiasing always on, which is useless and eye-straining unless PDF is blurry (e.g. a bad scan) anyway or you use something other than a proper monitor. Few controls, no meaningful config and even zoom is a little buggy.
While gv is good, but slow and it can't search text.

looks interesting francis. if/when that becomes available as bin via an ubuntu repo please say so.

Same problem here, xpdf crashes with https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1054482/+attachment/3354416/+files/atuer.pdf

That is xpdf 3.03 form the Ubuntu repositories.

I've fetched and installed the current xpdf binary package from Debian. Since it apparently is compiled with a compatible version of libpoppler (which is easily available and can be installed alongside the newer version), it works.

It evades me why Ubuntu thinks it is doing anybody a favor by delivering for several years now binaries that crash on every file. If they at least stopped distributing the crashing packages, people would be more likely to revert to the working Debian packages.

David, could you please please please (!) add detailed instructions - for 32 and 64 bit? I made the mistake of upgrading to 13.04 yesterday and now my workflow is severely disrupted :-(

@Andrew Tonks: Until David tells us the details, I can recommend xpdf_3.02-12ubuntu2nopoppler0_i386.deb for x32 which is an older version which works for me. I guess it is easy to find. With dpkg -i xpdf_3.02-12ubuntu2nopoppler0_i386.deb it should be installable.

Thanks Stefan, works for me

What I can do in steps to rise priority for this bug? Ubuntu really does not have any useful viewer now :(((

Just to add some more chaff to keep the bug alive:

1) to this day the bug persists in Ubuntu 13.04 raring;
2) a manual solution consists in downgrading to xpdf_3.02-21build2 as of comment #55 by Ronny Cardona (rcart) dated 2012-11-23;
3) to install this xpdf package I had to apt-get install libtiff4;
4) in order to prevent apt-get to re-upgrade xpdf to the broken repository package of 3.03-10ubuntu1, xpdf_3.02-21build2 has to be pinned in the following way:
    *) create file /etc/apt/preferences.d/xpdf contatining the following lines:

Package: xpdf
Pin: version 3.02-21build2
Pin-Priority: 1001

I personally disagree with David Kastrup who on 2013-03-17 wrote comment #70. It is indeed a shame xpdf has been broken for so long a time even though a solution to the well known cause has been around for a pretty long time. However, the solution is nor surrender, the repository package just has got to be fixed and next upgrade versions must be checked against this well known and long standing bug.

Regarding comment #76: sorry for the late reply, I am not reading this bug thread all too frequently any more (it's just too depressing). I just googled for the latest Debian .deb for xpdf, downloaded and installed it manually using "sudo dpkg -i [packagename.deb]". Which barfs and complains about a missing libpoppler library, so I downloaded that as well, and then did sudo dpkg -i on both packages.

Looking at my download directory, it would appear that the most recent possibly related downloads were
-rw-rw-r-- 1 dak dak 175754 Jul 12 12:30 xpdf_3.03-11ubuntu1_i386.deb
-rw-rw-r-- 1 dak dak 845206 Jul 12 12:32 libpoppler37_0.22.4-0ubuntu1_i386.deb
-rw-rw-r-- 1 dak dak 1194778 Jul 12 12:33 libxm4_2.3.4-4_i386.deb
-rw-rw-r-- 1 dak dak 13170 Jul 12 12:34 libmotif-common_2.3.4-4_all.deb

The proximity in download times makes it quite possible that libxm4 and libmotif-common were additional dependencies that I downloaded and installed, triggered by the respective complaint of dpkg (I don't actually remember doing that, but the modification times look suspiciously related, so it's likely that those were also involved). I used the Debian websites to locate the individual downloads and looked up the missing packages as they were announced by dpkg -i.

This bug was fixed in the package xpdf - 3.03-11ubuntu3

---------------
xpdf (3.03-11ubuntu3) saucy; urgency=low

  * Use GlobalParams module from Poppler and disable all settings that
    are not available in Poppler (LP: #943195, #1205732).
  * Remove fix-622877.patch and one hunk in
    track_libpoppler43_api_changes.patch that are no longer needed.
 -- Dmitry Shachnev <email address hidden> Wed, 04 Sep 2013 15:06:52 +0400

I've applied an ugly fix that just makes Xpdf use Poppler's GlobalParams module. The downside is that keybindings no longer work, but it's at least better than having Xpdf that doesn't start.

How do I install xpdf-3.03-11ubuntu3 on Ubuntu 13.4? If I do

sudo apt-get install xpdf

it tells me I have the latest version. Should this latest package not be a part of a normal update?

If the "fix" just applied disables controlling xpdf by the keys, then it's not a fix.
It totally escapes me why, since one can install xpdf from source (see #36 above) one can't simply package that and have done with it.

@Saurabh: it is available in 13.10 (aka Saucy).

@Ian: keybindings now work again in 3.03-11ubuntu5.

Any chance the fix gets backported to Raring? Evince is hella sluggish on my 50+ pages of LaTeX'd research notes.

I hope to be able to look at Raring backport next week.

@Dmitry: How about Precise backport?

@Vitaly: Sorry, I don't have enough time for that :(
Patches welcome, as usual.

I have prepared an update for raring in my ppa:mitya57/ppa. Please add that PPA, test the package and give your feedback.

@mitya57: I've installed xpdf for raring from your ppa and it has opened every pdf I have thrown at it so far.

Any chance to see that make it into the official Raring repositories soonish?

@David: it's currently stuck in the Unapproved queue: https://launchpad.net/ubuntu/raring/+queue?queue_state=1, you can try to ping the SRU team to see if they are going to approve it.

If it helps Dmitry - re a personal request from David Kastrup (above) via the LilyPond dev list - it works for me in Linux Mint 15 where xpdf was broken. I added your PPA and installed it that way.

James

This needs to be backported to precise, too.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23.10.2013 08:10, Matthias Andree wrote:
> This needs to be backported to precise, too.

Confirm!

- --
Don't visit my blog: http://demystifikation.wordpress.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJnc4IACgkQQeATqGpDnRqXpACgoYPaicTUG32vXzu/PcTrNkpa
h0UAn3yVYab3WufUhVyKXNeM6roP81IH
=IPSm
-----END PGP SIGNATURE-----

Can anybody say, why the priority in the upload queue is low?

The program crashes every time and doesn't work at all - so it should be high!

I really don't understand the priority feature at all...

BTW: Backport to Precise: +1

LAZA: The priority field has almost no effect in Ubuntu, so it really doesn't matter.

Hello Łukasz, or anyone else affected,

Accepted xpdf into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/xpdf/3.03-10ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Backport to Precise++

xpdf 3.03-1ubuntu1.1 from raring-proposed working for me

I am a user of neither Xpdf nor Precise, and I don't have any plans (or time) to do a backport, sorry. If someone else does I'll be happy to sponsor it.

This bug was fixed in the package xpdf - 3.03-10ubuntu1.1

---------------
xpdf (3.03-10ubuntu1.1) raring; urgency=low

  * Use GlobalParams module from Poppler and move all settings that
    are not available in Poppler to a separate file (LP: #943195).
 -- Dmitry Shachnev <email address hidden> Thu, 19 Sep 2013 18:14:03 +0400

3.03-10ubuntu1.1 (raring-updates) - works, thanks.

...of course, now it fails to understand "antialias no" explicitly set in .xpdfrc (sigh)

I recently upgraded to Xubuntu 13.10 with the xpdf package 3.03-11ubuntu6.

As TBeholder reported above, xpdf now runs without crashing, but the font display in the menus and index is abominable looking. It looks to me as if antialiasing of these fonts are not being used while those for the display document are. I have no ~/.xpdfrc but there is a global /etc/xpdf/xpdfrc initialization file.

Instead of trying to adjust antialiasing in the configuration file, I tried to set this and other parameters on the command line. What I discovered is that although xpdf -h reports these options, the following do not work:

-mattecolor <color> # error: "<color>" file not found
-z <value> # <value> is ignored
-t1lib <yes/no> # no message -- just displays help
-freetype <yes/no> # error: "<yes/no>" file not found
-aa <yes/no> # error: "<yes/no>" file not found
-aaVector <yes/no> # error: "<yes/no>" file not found
-paper <size> # error: "<size>" file not found

etc.

You get the idea. There is something seriously wrong with this build. These options all work on my Solaris build for version 3.02 of xpdf. The fact that you cannot set the antialias option on the command line may be a further key into the problem reported above. Please fix the program to get a font display that does not hurt so much to view it! :-) Thanks.

On 19/01/2014 05:18, C. Jeffery Small wrote:
> I recently upgraded to Xubuntu 13.10 with the xpdf package
> 3.03-11ubuntu6.
>
> As TBeholder reported above, xpdf now runs without crashing, but the
> font display in the menus and index is abominable looking. It looks to
> me as if antialiasing of these fonts are not being used while those for
> the display document are. I have no ~/.xpdfrc but there is a global
> /etc/xpdf/xpdfrc initialization file.
>
> Instead of trying to adjust antialiasing in the configuration file, I
> tried to set this and other parameters on the command line. What I
> discovered is that although xpdf -h reports these options, the following
> do not work:
>
> -mattecolor <color> # error: "<color>" file not found
> -z <value> # <value> is ignored
> -t1lib <yes/no> # no message -- just displays help
> -freetype <yes/no> # error: "<yes/no>" file not found
> -aa <yes/no> # error: "<yes/no>" file not found
> -aaVector <yes/no> # error: "<yes/no>" file not found
> -paper <size> # error: "<size>" file not found
>
> etc.
>
> You get the idea. There is something seriously wrong with this build.
> These options all work on my Solaris build for version 3.02 of xpdf.
> The fact that you cannot set the antialias option on the command line
> may be a further key into the problem reported above. Please fix the
> program to get a font display that does not hurt so much to view it!
> :-) Thanks.

  I would say this deserves a separate, new bug report.

  Have a good day,

xpdf has been renamed to xpdf.real, and xpdf now is a wrapper for xpdf.real. I tested -aa on xpdf.real and it works there.
As stated above though, this should be a new bug report.

@ C. Jeffery Small:

As our package is now (mostly) in sync with Debian, I have forwarded your bug report to the Debian maintainer:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736444

the patch from http://silas.psfc.mit.edu/xpdf3.03Viewer.patch is no longer available, found here: http://nawhko.tistory.com/66 attaching it to this post

I wanted to write "patch to comment #36" - I have built a working xpdf for Ubuntu 12.04 LTS with this.