Red Hat Bugzilla – Bug 131410
xpdf uses up all ram with particular pdf file
Last modified: 2007-11-30 17:10:48 EST
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: Always Steps to Reproduce: 1.run "top" in one terminal window 2. xpdf bug.pdf 3. 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.
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? Thanks.
What about the fact that my dual CPU + 7GB of virtual ram computer becomes unresponsive? Should be this bug cross-listed as a kernel bug as well? Sincerely, Dmitri.
Created attachment 105423 [details] another problem PDF file I found this file http://www.miami.muohio.edu/president/personal/w8zr/images/atc1_schematic.pdf (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!