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

[Łukasz Daniel]

Impact
------

All Xpdf users are affected. Xpdf fails to open any file and crashes.

Test case
---------

* Run "xpdf" and ensure that it starts.
* Run "xpdf somefile.pdf" and ensure that it starts.
* Ensure that keybindings (i.e. "o", "?") work.

Development fix
---------------

This was fixed in Saucy by making Xpdf use Poppler's GlobalParams module and splitting all Xpdf-specific params to XPDFParams module in debian/code/XPDFParams.{cc,h}.

Stable fix
----------

An adapted version of the fix is applied in package in raring-proposed.

Regression potential
--------------------

While there may be regressions in configuration handling compared to upstream Xpdf, having Xpdf that works is many times better than having Xpdf that crashes on any file.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: xpdf 3.02-21build1
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic x86_64
ApportVersion: 1.93-0ubuntu2
Architecture: amd64
Date: Wed Feb 29 12:42:12 2012
ExecutablePath: /usr/bin/xpdf.real
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcCmdline: xpdf.real -title Xpdf:\ cv_pl_LD.pdf cv_pl_LD.pdf
SegvAnalysis:
 Segfault happened at: 0x7f953cedd420 <_ZN7GooHash4hashEP9GooString>: mov 0x20(%rsi),%r8
 PC (0x7f953cedd420) ok
 source "0x20(%rsi)" (0x01010021) not located in a known VMA region (needed readable region)!
 destination "%r8" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: xpdf
StacktraceTop:
 GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::find(GooString*, int*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::lookup(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getResidentUnicodeMap(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getUnicodeMap2(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
UpgradeStatus: Upgraded to precise on 2012-02-19 (9 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

WORKAROUND: use Evince (Gnome/Unity) or Okular (Kubuntu)

[Apport retracing service (apport)]

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

[Launchpad Janitor (janitor)]

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

[David Kastrup (dak)]

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.

[David Kastrup (dak)]

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

[David Kastrup (dak)]

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.

[Marius B. Kotsbak (mariusko)]

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

[David Kastrup (dak)]

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.

[Marcel Stimberg (marcelstimberg)]

@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.

[Shouri Chatterjee (shouri)]

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.

[Shouri Chatterjee (shouri)]

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?

[dreckkopf (dreckkopf)]

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.

[Marius B. Kotsbak (mariusko)]

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?) ?

[davidg (davidg2603)]

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.

[arnuschky (abrutschy)]

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

[gamx (gllobet)]

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.

[Christoph (christoph-pleger-cs)]

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.

[Lorenzo Bettini (bettini)]

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

[halfdog (halfdog)]

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.

[Patrick Koppenburg (patrick-koppenburg)]

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?

[Christoph Sarnowski (pixelbrei)]

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.

[Patrick Koppenburg (patrick-koppenburg)]

Thanks! I have xpdf working again :-)

[Nick Dokos (nicholas-dokos)]

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?

[oddhack (developer-oddhack)]

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.

[D J Gardner (djgardner)]

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!)

[Eric Anderson (kluwak)]

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).

[roots (roots)]

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

[Iain Murray (ubuntu-iainmurray)]

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.

[israel vainsencher (israel-mat)]

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

[roots (roots)]

@ 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

[Ron Bakker (r0n)]

The same problem in Xubuntu 12.10 alpha-1.

[corrado venturini (corradoventu)]

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

[TBeholder (turbobeholder)]

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

> The following extra packages will be installed:
> libpoppler19

[Ian Hutchinson (hutch)]

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

[Marius B. Kotsbak (mariusko)]

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

[Ashok Popat (ashok-popat)]

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

[Ralf Hildebrandt (ralf-hildebrandt)]

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 ()

[TBeholder (turbobeholder)]

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.

[yitzhakbg (yitzhakbg)]

From what I can discern, the problem has to do with the Chinese.
Notice the crash info from libpopller in /var/log/kern.log.
I moved the unneeded xpdfrc language files out of /usr/share/xpdf and the problem disappeared

[Logan Rosen (logan)]

Happening with this PDF in a duplicate bug: https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1054482/+attachment/3354416/+files/atuer.pdf

[Logan Rosen (logan)]

And this one: https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1048608/+attachment/3305419/+files/aaa.pdf

[TBeholder (turbobeholder)]

> I moved the unneeded xpdfrc language files out of /usr/share/xpdf and the problem disappeared

doesn't work for me, whether moving away all of them, or leaving latin, same crash; 3.02-12+squeeze1 works with all those unicodeMap files or or without any.

[funicorn (funicorn)]

Ubuntu 12.10 is coming in two days, and xpdf is still crashing. What a loser ubuntu.

[funicorn (funicorn)]

I'm working on Ubuntu 12.10 by the way, which I think has already been the to-be-released version.

[funicorn (funicorn)]

I tried to build the official source package and failed during make. The error is about wrongly using functions in some head file. I wonder the binary deb is built with special tricks which successfully produces a unusable package.

[David Kastrup (dak)]

Crashed and burnt on Quetzal as before (i386 for me). Downgraded xpdf back to 3.02-21 and marked it as hold again. Pitiful.

[Bill Pringlemeir (bpringlemeir)]

Please update /etc/mailcap if you are going to leave this bug. Any program that uses mailcap will use xpdf for viewing pdf's.

[Natim (site-remy)]

I have the same bug over there.

[David McQuire (david-kenpro)]

I've go t xpdf working using #36 and #38 above, ie: apt-get --purge remove xpdf, then compile from source, but when i tried to add xpdf to the main menu in Ubuntu 12.04 Unity, alacarte crashed.

I have to start xpdf from the command line (which works fine).

Different problem, but very annoying. Any suggestions?

[David McQuire (david-kenpro)]

Answering my own question.....

It seems that Alacarte needs gnome-panel before you can update Unity's launching process with applications installed from source. Does this mean Ubuntu gods don't want anything installed from source?

So ... after building xpdf from source, I had to do:

sudo apt-get install gnome-panel

then I could use Alacarte or Main Menu (same thing apparently) to add xpdf to Unity's launching protocols.

[oddhack (developer-oddhack)]

Rebuilding from source per #36 also works for me.

[Ronny Cardona (rcart)]

Hello everybody and thanks for all your comments, I've read them all.

I will work on this bug and try to fix it or get it correctly <a href="https://wiki.ubuntu.com/Bugs/HowToTriage/">triaged</a>, it's been a long time and cannot be present anymore. I've recollected all the fixes that you've found, your processes to reproduce the bug (that I've already successfully confirmed) and hopefully I'll will be with more news over here.

Thanks for your comments and please be more patient.

[Ronny Cardona (rcart)]

Hello again.

I've successfully applied the patch from debian [1] and xpdf works fine for me, a least against this bug. Please test it from my ppa:
sudo add-apt-repository ppa:rcart/testing
sudo apt-get update
sudo apt-get install xpdf

Or you could just install the deb package from:
http://ubuntuone.com/2EJaYcRLbaWVVAvNQqDxBF

This fix is just for 64bits, let me know if works for you and then I'll create the 32 bits package as well.

Please leave me your comments and thanks in advance.

[1] http://bugs.debian.org/658264#49

[twin (twin)]

The package from

http://ubuntuone.com/2EJaYcRLbaWVVAvNQqDxBF

works for me.

[Benjamin Griffin (bgriffin)]

The xpdf in xpdf_3.02-21build2_amd64.deb from http://ubuntuone.com/2EJaYcRLbaWVVAvNQqDxBF works for me, too.

[Stefan Wagner (wagner-stefan)]

On a 32- bit Intel system, the 12.04 (LTS) version of xpdf crashes. Imho, there should be a fix for the LTS-version, but I would be interested in workarounds (beside using evince or something) too.

Opening xpdf without any file works, but opening a file - any pdf-File - and Segfault (isn't this a serious security issue? Shouldn't every program be sanitized against segfaulting?).

Here is my strace-output:
<pre>
execve("/usr/bin/xpdf", ["xpdf", "Downloads/GFP-ENAU.pdf"], [/* 45 vars */]) = 0
brk(0) = 0x8377000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7739000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=62852, ...}) = 0
mmap2(NULL, 62852, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7729000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\226\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1730024, ...}) = 0
mmap2(NULL, 1743580, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x22e000
mprotect(0x3d1000, 4096, PROT_NONE) = 0
mmap2(0x3d2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a3) = 0x3d2000
mmap2(0x3d5000, 10972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3d5000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7728000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7728900, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x3d2000, 8192, PROT_READ) = 0
mprotect(0x8060000, 4096, PROT_READ) = 0
mprotect(0x5da000, 4096, PROT_READ) = 0
munmap(0xb7729000, 62852) = 0
getpid() = 14899
rt_sigaction(SIGCHLD, {0x8056220, ~[RTMIN RT_1], 0}, NULL, 8) = 0
geteuid32() = 1000
brk(0) = 0x8377000
brk(0x8398000) = 0x8398000
getppid() = 14898
stat64("/home/stefan", {st_mode=S_IFDIR|0700, st_size=8152, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0700, st_size=8152, ...}) = 0
open("/usr/bin/xpdf", O_RDONLY) = 3
fcntl64(3, F_DUPFD, 10) = 10
close(3) = 0
fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x8056220, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
read(10, "#!/bin/sh\n# Copyright (c) 2001 A"..., 8192) = 2138
stat64("Downloads/GFP-ENAU.pdf", {st_mode=S_IFR...

[Stefan Wagner (wagner-stefan)]

I tried the suggested version from Ursulinhas webpage without much hope, since it dates from "Published on 2011-05-02", and I'm using 12.04, which is labelled "3.02" too. But that works like a charm!

What prevents a fix from 11/05 to move into the version from 12/04, which is - from the name - the same version? I don't get it!

[raymond (drndzinisa)]

I am trying out the suggestion given Ian (#36) with the modification for a 32 bit machine
as suggested by #38. My machine runs on Ubuntu 12.10.
But I get confused at the "patching" step. The "wget ..." seemingly leads to a patch file
(the xpdf3.03Viewer.patch file). This is what I get upon running "patch < xpdfViewer.patch"
on the terminal :

raymond@raymond-HP-625:~/Downloads/xpdf-3.03$ patch < xpdf3.03Viewer.patch
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- xpdf/XPDFViewer.cc~ 2011-08-15 17:08:53.000000000 -0400
|+++ xpdf/XPDFViewer.cc 2012-09-02 11:59:32.000000000 -0400
--------------------------
File to patch:

If I then enter
./configure --with-freetyep2-library=/usr/lib/i386-linux-gnu
./configure --with-freetyep2-library=/usr/lib/i386-linux-gnu

I get this (" No such file or directory
Skip this patch? [y] "), like
./configure --with-freetyep2-library=/usr/lib/i386-linux-gnu
./configure --with-freetyep2-library=/usr/lib/i386-linux-gnu: No such file or directory
Skip this patch? [y]

Could you help with some clarification please. I alread have the xpdf source downloaded.

[Nick Payne (nick-payne)]

xpdf 3.03 in 12.10 crashed at startup with every single PDF file I tried it with. I downloaded the source for 3.03 from http://www.foolabs.com/xpdf/download.html, and when built and installed that ran without problem:

sudo apt-get install libfreetype6-dev lesstif2-dev
wget ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.03.tar.gz
tar xzpf xpdf-3.03.tar.gz
cd xpdf-3.03
export CXXFLAGS=-fpermissive
./configure --with-freetype2-library=/usr/lib/x86_64-linux-gnu \
    --with-freetype2-includes=/usr/include/freetype2 \
    --with-Xm-library=/usr/lib \
    --with-Xm-includes=/usr/include/Xm
make
sudo make install

[Ronny Cardona (rcart)]

Here's a 32bits package for precise: http://ubuntuone.com/5mYDX5lzyza2h7fPjbwKIh

At the moment, I can't fix the Quantal package and SRU [1] just applies when the bug is fixed in the Development version as well (Raring, but Raring and Quantal has the same package).

I'm still working on this.

[1] https://wiki.ubuntu.com/StableReleaseUpdates

[David Kastrup (dak)]

Any news about when to expect a fix in Quantal? It has been two months since the last message.

[MMlosh (mmlosh)]

Oh, a fix was promised? That's great news, even if two months old.
Time to get my testing machine running raring then...

xpdf was broken for at least a year in the past. Then it worked in one ubuntu release. Now it's broken again.
I am quite surprised that things were moving

[Ronny Cardona (rcart)]

Hello people.

It's been a while since the last update. I must say that I've been trying to apply the patch in Quantal but there are others problems with libpoppler (which is a higher version than precise) that I can't fix.

I've been tracking updates in Debian's bug report, but seems like this problem *is not a trivial fix* and is completely out of my Kung-Fu. Debian maintainer refused to apply some patches to fix this bug due to "future problems" whit this package.

So, I'm leaving the bug and invite you to read the explanation in the last update of the mentioned bug report[1].

I will mail Ubuntu Developers mailing list to inform about this *serious* bug so they can take a decision about it, or maybe some developer starts to work on this bug.

Thanks.

[1]http://bugs.debian.org/bug=658264#95

[Ronny Cardona (rcart)]

Sorry for the bad link.

Here: http://bugs.debian.org/658264#95

[Marius B. Kotsbak (mariusko)]

Could anyone please test if this still fails in the latest daily builds of Raring (13.04)?

[Logan Rosen (logan)]

Yes, this is still occurring in raring with xpdf 3.03-10ubuntu1 with the following PDF file: https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1054482/+attachment/3354416/+files/atuer.pdf

[MMlosh (mmlosh)]

I moved to raring today..
Nothing changed.
Still a brief flash of the pdf document followed by a crash.

[David Kastrup (dak)]

xpdf should get removed from Ubuntu. There is no point in delivering an entirely unusable binary package that just crashes, and it may well be a security risk.

It also makes it harder to actually find the last working version of xpdf to install when Ubuntu delivers a non-crashing xpdf only one time out of five. I don't understand at all why Ubuntu does not just deliver the last working version instead of insisting on a crashing one, but it no working version can be delivered, it would be better to deliver none in future.

[Thangalin (thangalin-deactivatedaccount)]

https://github.com/FrancisRussell/xpdf-lite

[gregrwm (gregrwm)]

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

[Νίκος Αλεξανδρής (nikos.alexandris)]

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

[Νίκος Αλεξανδρής (nikos.alexandris)]

That is xpdf 3.03 form the Ubuntu repositories.

[David Kastrup (dak)]

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.

[Andrew Tonks (a-tonks)]

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 :-(

[Stefan Wagner (wagner-stefan)]

@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.

[Andrew Tonks (a-tonks)]

Thanks Stefan, works for me

[vitaly.v.ch (vitaly-v-ch)]

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

[Alessandro Selli (alessandroselli)]

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.

[David Kastrup (dak)]

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.

[Launchpad Janitor (janitor)]

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

[Dmitry Shachnev (mitya57)]

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.

[Saurabh Rindani (saurabh-prl)]

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?

[Ian Hutchinson (hutch)]

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.

[Dmitry Shachnev (mitya57)]

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

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

[Luke Maurer (luke-maurer)]

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

[Dmitry Shachnev (mitya57)]

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

[vitaly.v.ch (vitaly-v-ch)]

@Dmitry: How about Precise backport?

[Dmitry Shachnev (mitya57)]

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

[Dmitry Shachnev (mitya57)]

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

[Graham Inggs (ginggs)]

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

[David Kastrup (dak)]

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

[Dmitry Shachnev (mitya57)]

@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.

[James (pkx166h-1)]

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

[Matthias Andree (matthias-andree)]

This needs to be backported to precise, too.

[Stefan Wagner (wagner-stefan)]

-----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-----

[LAZA (laza74)]

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

[Colin Watson (cjwatson)]

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

[Colin Watson (cjwatson)]

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!

[Lenin (gagarin)]

Backport to Precise++

[Graham Inggs (ginggs)]

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

[Dmitry Shachnev (mitya57)]

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.

[Launchpad Janitor (janitor)]

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

[TBeholder (turbobeholder)]

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

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

[C. Jeffery Small (loyhz2ay-jeff-h670zbts)]

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.

[Alessandro Selli (alessandroselli)]

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,

[Siep Kroonenberg (siepo)]

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.

[Dmitry Shachnev (mitya57)]

@ 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

[Martin Hecht (mrbaseman)]

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

[Martin Hecht (mrbaseman)]

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