From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
XPDF uses up all awailable (addressable) memory (RAM+swap) trying to open
the attached pdf. Computer becomes completely unresponsive (is this also
a kernel issue?), requires power cycle to recover.
Both acroread or ggv (ghostscript) displays the file correctly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.run "top" in one terminal window
2. xpdf bug.pdf
Actual Results: Top shows that all ram and some swap is used up bu
xpdf, after which
computer becomes unresponsive. Xpdf displays gray window with hourglass in
it. Attempts to ssh into the computer times out. Ctrl-Alt-Backspace or
Ctrl-Alt-F1 etc. do not seems to do anything (at least after few
Expected Results: xpdf displays the file. Failing that kernel should
degrade more gracefully.
2XAthlonMP 2000GHz, 1 GB RAM, 6GB swap.
Created attachment 103323 [details]
pdf file that causes the problem.
it looks like a bug in g++. xpdf works fine if it's built with -O0 or
-O1, but not with -O2 or higher.
it's reproduceable with current gcc in RHEL3/fc1/fc2 and fc3test.
That doesn't mean there is a g++, actually it is far more likely
an application bug than g++ bug.
Especially when RHEL3..FC3test have very different GCCs.
If you are sure this is not xpdf bug, can you create a (small) testcase
which reproduces the problem?
What about the fact that my dual CPU + 7GB of virtual ram computer
unresponsive? Should be this bug cross-listed as a kernel bug as well?
Created attachment 105423 [details]
another problem PDF file
I found this file
(about 400K) which has the same effect.
No change in behavior in xpdf-3.00-3.4.
Andre, i'm still debugging this problem.
Very strange behavior observed. First, this bug still exists with
xpdf-3.00-10.4 in FC3, using the command
xpdf atc1_schematic &
BUT, when I ran the command
strace -f -o xpdf.txt xpdf atc1_schematic.pdf &
to see what's happening, it successfully displays the file!
I can open atc1_schematic with both xpdf and gpdf though the vertual/resident
size of each of them would go almost up to 400M. Here is another fun fact
about atc1_schematic.pdf. runing pdf2ps on makes a 13 Meg file
atc1_schematic.ps. Runing ps2ps atc1_schematic.ps atc1_schematic2.ps
results in 206M atc1_schematic2.ps:
[dima@localhost tmp]$ ls -lh *.ps
-rw-rw-r-- 1 dima dima 206M Mar 21 21:39 atc1_schematic2.ps
-rw-rw-r-- 1 dima dima 13M Mar 21 21:35 atc1_schematic.ps
I guess I need to try to do the same with more a recent ghostscript...
the xpdf-3.00-10.4 can display this pdf testcase without any problem for me.
because of the rendering it could take some minutes on slower machine!