xpdf segfaults

[Chip Piller]

Using the firefox browser I navigate to web pages with pdf links. I right click
on the pdf link and select open in new tab. A popup window asks if I want to
open using xpdf, I say yes, firefox downloads the file and xpdf opens the pdf file.

I then open a few xpdf windows this way and leave them up and running for
several days. Then I try to open another pdf file the same way except this time
it does not work. So instead of using xpdf to open the file I choose to save as
a file, and then I right click in an xpdf window and open the file. This will
work a couple of times but then that approach stops working.

Finally, all xpdf windows crash and I am unable to run xpdf at all. If I try to
run xpdf from a command line it immediately gives the message "Segmentation
fault".

This same xpdf behaviour has now happened at least twice, the first time I
closed all apps, logged out and then logged back in and xpdf started to work again.

[Chip Piller (piller)]

I tried to use command line tool pdf2ps and it also fails:

piller@piller64 ~ $ pdf2ps an1048.pdf an1048.ps
Error: /undefined in 59660449e.pdf
Operand stack:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3
%oparray_pop 1 3 %oparray_pop .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval--
Dictionary stack:
   --dict:1054/1417(ro)(G)-- --dict:0/20(G)-- --dict:68/200(L)--
Current allocation mode is local
Current file position is 16
ESP Ghostscript 7.07.1: Unrecoverable error, exit code 1
piller@piller64 ~ $

[Matt Zimmerman (mdz)]

Are these PDF files very large? Is it possible that you are running out of
memory or disk space?

The next time this happens, collect the following information and attach to the bug:

Output from "ps aux"
Output from "free -m"
Output from "df -h"
Output from "strace xpdf <some PDF file>", assuming it fails

[Chip Piller (piller)]

Created an attachment (id=675)
command output, strace output

[Matt Zimmerman (mdz)]

Please try to get a gdb backtrace from xpdf:

$ gdb xpdf.bin
(gdb) run
<reproduce segfault, should drop back to (gdb) prompt>
(gdb) bt

[Chip Piller (piller)]

Created an attachment (id=685)
xpdf segfault gdb backtrace

[Matt Zimmerman (mdz)]

Tollef, any idea about this? It seems potentially amd64-specific

[Tollef Fog Heen (tfheen)]

programs not behaving the same on each invocation sounds a bit like hardware
issues, not software problems.

I'm using xpdf quite a lot on my AMD64 without any problems.

Also, if you can try to get a backtrace from xpdf without TLS enabled, it would help:

LD_ASSUME_KERNEL=2.4.1 gdb xpdf.bin

[Chip Piller (piller)]

Created an attachment (id=692)
backtrace using LD_ASSUME_KERNEL=2.4.1 gdb xpdf.bin

Attached is requested backtrace.

I have closed all applications, logged out of my desktop and then logged back
in and xpdf appears to run fine again. We will see for how long.

As for hardware, the machine is a two month old HP Pavilion a650e: Athlon64
3200+ cpu, Asus K8N8X-LA motherboard, Nvidia nForce3 150 chipset, 1 GB DDR ram,
Nvidia 128 MB DDR GeForceFX 5200XT graphics card.

I entered another bug https://bugzilla.ubuntu.com/show_bug.cgi?id=2831 for this
machine, the mouse will occasionally move by itself. I believe that this is
because I am using the supplied optical mouse without an appropriate surface.
Other than this I have had no problems with the machine.

Please let me know if you need any other information.

[Matt Zimmerman (mdz)]

Do you see any messages in the output from the dmesg command after xpdf
segfaults? Anything in /var/log/XFree86.0.log?

[Matt Zimmerman (mdz)]

I tested on a Pavilion a650e, opened a huge number of xpdf windows, left them
open for some time, opened some more. I am unable to reproduce any problem.

[Chip Piller (piller)]

Created an attachment (id=699)
dmesg output

I did not see anything in /var/log/XFree86.0.log, but there are some things in
dmesg, see attachment. Glad to see that you have access to the same Pavilion
a650e hardware. At the moment xpdf is working fine here.

[Tollef Fog Heen (tfheen)]

The segfault messages from the kernel is just because those are turned on by default for
amd64 kernels. They don't tell us anything apart from "xpdf segfaulted", which we already
knew.

Do you see this problem with some PDFs in particular? It would be useful if mdz or I could
try reproducing with the same PDFs as you are using. (If you are able to redistribute them.)

[Tollef Fog Heen (tfheen)]

I think this might be related to the fakeroot problems we had with glibc.

Chip, are you still able to reproduce this problem? If so, could I please get a copy
of one of the problematic PDFs?

[Chip Piller (piller)]

Created an attachment (id=772)
pdf file that may have caused problem

This is one of the files that I think was causing problems. One thing I found
is that if I run the pdf2ps command on this file that it fails, but that the
command pdftops succeeds. I don't know why but both commands are installed on
my ubuntu system.
I have been away for the last week and have not been able to try to reproduce
the original problem on my machine.

[Chip Piller (piller)]

Created an attachment (id=773)
another suspect pdf??

This pdf may also have caused the original problem, it fails for me when I try
pdf2ps but succeeds with pdftops (which I tried when xpdf failed).

[Chip Piller (piller)]

Created an attachment (id=867)
command output

xpdf segfault problem has returned today to my amd64 machine. My machine has
been up now for 31 days, xpdf has been working fine until today when I tried to
open a pdf link from a firefox tab.

[Chip Piller (piller)]

Created an attachment (id=868)
gdb backtrace info from xpdf

xpdf cannot be started now without a segfault.

[Chip Piller (piller)]

Created an attachment (id=869)
strace output

Awaiting words of wisdom from developers .... I will try to keep machine in
it's present state, that is to not log out/reboot.

[Matt Zimmerman (mdz)]

This is starting to sound like a 64-bit uncleanness issue. It probably has to
do with the address where xpdf happens to be loaded in memory.

[LaMont Jones (lamont)]

This is what we call a _BIG_ clue:

g++ -g -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi -I./../splash -I.
-I/usr/include/freetype2 -I/usr/include -I/usr/X11R6/include -c
XPDFViewer.cc
XPDFViewer.cc: In member function `void XPDFViewer::initWindow()':
XPDFViewer.cc:722: warning: cast to pointer from integer of different size
XPDFViewer.cc: In static member function `static void
   XPDFViewer::zoomMenuCbk(_WidgetRec*, void*, void*)':
XPDFViewer.cc:1383: warning: cast from pointer to integer of different size

[Tollef Fog Heen (tfheen)]

I have some (hoary-built) debs on http://err.no/tmp/xpdf/ . The diff is at
http://err.no/patches/xpdf_3.00-11ubuntu3_intisnotpointer.diff

If you could try those new packages and see if they fix the issue for you, that
would
be great.

If you are running warty, tell me and I'll build the packages for you on warty.

[Tollef Fog Heen (tfheen)]

My patch has been integrated in Debian and we've later synced, so closing this bug.