Evince crashes when zooming PDF-File to 400%

[Kuropka]

Evince starts with wild swapping and finally crashed on my machine when Zooming
the attached PDF-File to 400%.

http://bugzilla.gnome.org/show_bug.cgi?id=321138

[Kuropka (d2)]

Created an attachment (id=4787)
A sample PDF-File

[Sebastien Bacher (seb128)]

Thanks for your bug. Does it crash or is ejected because it uses too much
ressources? Do you get a bug-buddy dialog when that happens?

[Kuropka (d2)]

I did not get a bug-buddy report. So it probably consumed to many resources. The
computer has 512 MByte Ram + the same SWAP Ram. So such a resource consumption
seems to be more or less a bug and not a feature ;-)

Furthermore, XPDF has no problems with presenting the file at 400%.

[Sebastien Bacher (seb128)]

I've forwarded the issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=321138

[Oleksij Rempel (olerem)]

I get same issue with big djvu files.

For example:
"Pennsylvania County Type 10 Maps in DJVU Format"

http://www.dot.state.pa.us/Internet/Bureaus/pdPlanRes.nsf/infoBPRCountyType10MapsDJVU?OpenForm&AutoFramed

djvudump franklin_GHSN.djvu
  FORM:DJVU [720740]
    INFO [10] DjVu 13200x18600, v25, 300 dpi, gamma=2,2
    CIDa [36]
    Sjbz [621454] JB2 bilevel data
    FGbz [6340] JB2 colors data
    BG44 [23602] IW4 data #1, 72 slices, v1.2 (color), 4400x6200
    BG44 [11380] IW4 data #2, 11 slices
    BG44 [19832] IW4 data #3, 10 slices
    BG44 [38018] IW4 data #4, 10 slices

This file will crash with zoom 200 % on my system with 2GB RAM and 2GB SWAP

[gwern (gwern0)]

I'd just like to note that I can reproduce this in the latest Hardy Heron on my system with 4 GB of RAM, using the Vorlesung PDF example at 400%; in fact, I don't even need to scroll. Attached is an strace log.

gwern@craft:10575~>strace -o vorlesun-evince-trace.txt evince Vorlesung_v4.pdf [ 2:41PM]
The program 'evince' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 1135 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
gwern@craft:10576~>evince --version [ 2:42PM]
GNOME evince 2.22.2

[levien (levien)]

I have been experiencing possibly the same problem with evince and any PDF-file which has scanned pages (e.g. any scientific article from before 1995 or so, such as this one: http://www.pubmedcentral.nih.gov/picrender.fcgi?artid=1215979&blobtype=pdf )

These documents seem to open just fine at first, but then the system just locks up swapping and eventually evince is killed due to lack of resources. Zooming to 400% is not even needed. Monitoring with top shows that the evince process fills up all available memory, followed by all available swap space, until it is killed.

I'm using evince on an up-to-date 8.04 Hardy Heron system with 512 Mb memory and 512 Mb swapspace. The same documents open fine with KPDF and acroread on the same system, and with evince on a Feisty system. PDF documents without scanned pages seem to open just fine in evince as well.

[Dimitrios Symeonidis (azimout)]

i can still reproduce this in Intrepid

[fp (fakepop)]

I can reproduce in Jaunty.

[Dimitrios Symeonidis (azimout)]

Seems resolved in Karmic: it does provoke some heavy disk activity in the beginning (maybe 10 seconds) but no crash, and then I can browse the document without a problem...

[Dimitrios Symeonidis (azimout)]

removing upstream bug watch, which is irrelevant (a feature request to increase the maximum zoom level above the current 400%)

[Dimitrios Symeonidis (azimout)]

Is this still an issue for anyone on Jaunty or Karmic? Thank you

[Bartek (tschew)]

Dimitrios,

The bug is still present: the allocation method (which is responsible for this bug) has not changed. Pages are loaded into memory as one big image which is then displayed. Once there's no memory left, the operating system terminates the process as it should.

The only way to fix this is to implement a tile loader in evince and a proximity loading algorithm (tile the page up, load tiles adjacent to the ones currently on display, load tiles that are about to come into view as the document is scrolled).

Also, the upstream bug you marked as irrelevant is relevant because the 400% limit and the crashing due to insufficient memory are related. (as is explained in the comments) The artificial limit has been put there to prevent these crashes in most use cases. (but it's obviously a hack, and not a good one).

Cheers,
-Bartek

[Dimitrios Symeonidis (azimout)]

Ok Bartek, thanks for clearing this out. I have switched this back to confirmed and restored the upstream bug watch.

Now, could you please update the description of this bug to reflect what you wrote in comment 13?

Thank you

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Marking as triaged since upstream confirmed the bug.

[Scott Lewin (sclewin)]

+1 in Karmic. Evince is very slow when opening pdf files and crashes many times on resizing. It does not even need to be to 400%, any size. I have attached a pdf file that always causes the problems for me.

[Steven Richards (steven.richards)]

This is not appear to be an issue in Natty, opened the Ubuntu-Manual to test, works very fast.

[papukaija (papukaija)]

@ Heru Herdianto :

Please, *don't* play with the form options. Thanks in advance.

[papukaija (papukaija)]

Please reopen this bug - the Ubuntu Manual (assuming the one which is opened through system menus) has nothing to do with Evince.

[Pedro Villavicencio (pedro)]

Please open a new bug if you're still seeing this, either enable apport to report the crash or use ubuntu-bug evince. Thanks all.