Bug 131410 - xpdf uses up all ram with particular pdf file
Summary: xpdf uses up all ram with particular pdf file
Alias: None
Product: Fedora
Classification: Fedora
Component: xpdf
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-01 01:21 UTC by Dmitri A. Sergatskov
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-03-22 13:45:04 UTC

Attachments (Terms of Use)
pdf file that causes the problem. (667.90 KB, application/octet-stream)
2004-09-01 01:23 UTC, Dmitri A. Sergatskov
no flags Details
another problem PDF file (431.61 KB, application/pdf)
2004-10-19 05:17 UTC, Andre Robatino
no flags Details

Description Dmitri A. Sergatskov 2004-09-01 01:21:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

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):
xpdf-3.00-3, kernel-smp-2.6.8-1.521

How reproducible:

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

Expected Results:  xpdf displays the file. Failing that kernel should
degrade more gracefully.

Additional info:

2XAthlonMP 2000GHz, 1 GB RAM, 6GB swap.

Comment 1 Dmitri A. Sergatskov 2004-09-01 01:23:46 UTC
Created attachment 103323 [details]
pdf file that causes the problem.

Comment 2 Ngo Than 2004-09-15 16:45:37 UTC
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.

Comment 3 Jakub Jelinek 2004-09-15 16:55:26 UTC
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?


Comment 4 Dmitri A. Sergatskov 2004-09-15 18:54:59 UTC
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?


Comment 5 Andre Robatino 2004-10-19 05:17:24 UTC
Created attachment 105423 [details]
another problem PDF file

  I found this file
(about 400K) which has the same effect.

Comment 6 Andre Robatino 2004-10-21 21:34:41 UTC
  No change in behavior in xpdf-3.00-3.4.

Comment 7 Ngo Than 2004-10-22 08:57:07 UTC
Andre, i'm still debugging this problem.

Comment 8 Andre Robatino 2005-03-22 00:16:15 UTC
  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!

Comment 9 Dmitri A. Sergatskov 2005-03-22 04:44:57 UTC
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...

Comment 10 Ngo Than 2005-03-22 13:45:04 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.