Bug 6680 - evince hangs eating CPU when rendering a pdf page
Summary: evince hangs eating CPU when rendering a pdf page
Status: RESOLVED DUPLICATE of bug 13518
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-20 22:46 UTC by Sebastien Bacher
Modified: 2009-06-17 13:05 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Sebastien Bacher 2006-04-20 22:46:00 UTC
That bug has been opened on
https://launchpad.net/distros/ubuntu/+source/gpdf/+bug/38674

"f you go to http://www.mises.org/etexts/cwik-dissertation.pdf and download the
pdf, you can check if the problem exists for you too.

This pdf works under Win XP and Adobe Acrobat. I'm not sure what is causing the
failure with gpdf but it fails with evince as well. gpdf's problem is
particularly bad as it hangs.

To replicate:
1. Open pdf
2. Scroll down to page 13-14 (the sideways page is the one that does it)
...


Here's a backtrace but evine doesn't appear to be "stuck" in one function and
consequently continuing and then getting another backtrace yields something
different.

Thread 2 (Thread -1230013520 (LWP 8751)):
#0 0xb79978b9 in Parser::getObj () from /usr/lib/libpoppler.so.1
#1 0xb79a31a2 in XRef::fetch () from /usr/lib/libpoppler.so.1
#2 0xb79935d8 in Object::fetch () from /usr/lib/libpoppler.so.1
#3 0xb7945de5 in Dict::lookup () from /usr/lib/libpoppler.so.1
#4 0xb7950117 in GfxResources::lookupGState () from /usr/lib/libpoppler.so.1
#5 0xb79501c2 in Gfx::opSetExtGState () from /usr/lib/libpoppler.so.1
#6 0xb794e7a4 in Gfx::execOp () from /usr/lib/libpoppler.so.1
#7 0xb794ea57 in Gfx::go () from /usr/lib/libpoppler.so.1
#8 0xb794f675 in Gfx::display () from /usr/lib/libpoppler.so.1
#9 0xb7953136 in Gfx::doForm1 () from /usr/lib/libpoppler.so.1
#10 0xb7954922 in Gfx::doTilingPatternFill () from /usr/lib/libpoppler.so.1
#11 0xb795902f in Gfx::doPatternFill () from /usr/lib/libpoppler.so.1
#12 0xb79593ec in Gfx::opFill () from /usr/lib/libpoppler.so.1
#13 0xb794e7a4 in Gfx::execOp () from /usr/lib/libpoppler.so.1
#14 0xb794ea57 in Gfx::go () from /usr/lib/libpoppler.so.1
#15 0xb794f675 in Gfx::display () from /usr/lib/libpoppler.so.1
#16 0xb7996e10 in Page::displaySlice () from /usr/lib/libpoppler.so.1
#17 0xb7a3190a in poppler_page_render_to_pixbuf () from
/usr/lib/libpoppler-glib.so.1
#18 0x0809119c in pdf_document_get_type ()
#19 0x0808f494 in ev_document_render_pixbuf ()
#20 0x0806490f in ev_job_render_run ()
---Type <return> to continue, or q <return> to quit---
#21 0x0806338b in ev_document_types_add_filters ()
#22 0x08063490 in ev_document_types_add_filters ()
#23 0xb6e5d472 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#24 0xb7a3c341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#25 0xb77c54ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread -1228515648 (LWP 8749)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb77bb8c4 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb6e446e8 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3 0xb6e44bb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4 0xb735d3c6 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5 0x0807faab in main ()
#0 0xffffe410 in __kernel_vsyscall ()

Valgrind did report the following though:
==8940==
==8940== Thread 2:
==8940== Conditional jump or move depends on uninitialised value(s)
==8940== at 0x469BDFD: Splash::strokeNarrow(SplashXPath*) (in
/usr/lib/libpoppler.so.1.0.0)
==8940== by 0x469C775: Splash::stroke(SplashPath*) (in /usr/lib/libpoppler.so.1.0.0)
==8940== by 0x45FD073: SplashOutputDev::stroke(GfxState*) (in
/usr/lib/libpoppler.so.1.0.0)
==8940== by 0x461354D: Gfx::opStroke(Object*, int) (in /usr/lib/libpoppler.so.1.0.0)
==8940== by 0x46117A3: Gfx::execOp(Object*, Object*, int) (in
/usr/lib/libpoppler.so.1.0.0)
==8940== by 0x4611A56: Gfx::go(int) (in /usr/lib/libpoppler.so.1.0.0)
==8940== by 0x4612674: Gfx::display(Object*, int) (in /usr/lib/libpoppler.so.1.0.0)
==8940== by 0x4659E0F: Page::displaySlice(OutputDev*, double, double, int, int,
int, int, int, int, int, Links*, Catalog*, int (*)(void*), void*, int
(*)(Annot*, void*), void*) (in /usr/lib/libpoppler.so.1.0.0)
==8940== by 0x45B4909: poppler_page_render_to_pixbuf (in
/usr/lib/libpoppler-glib.so.1.0.0)
==8940== by 0x809119B: (within /usr/bin/evince)
==8940== by 0x808F493: ev_document_render_pixbuf (in /usr/bin/evince)
==8940== by 0x806490E: ev_job_render_run (in /usr/bin/evince)
...
"
Comment 1 Albert Astals Cid 2006-04-20 23:16:05 UTC
Having a quick look at the backtrace seems the infamous "patterns are slow" 
bug. 

http://bugs.kde.org/show_bug.cgi?id=99486

If it is this bug, you are right, it's not hanged, give it LOTS OF TIME, and 
it'll finish.
Comment 2 Sebastien Bacher 2006-04-20 23:33:23 UTC
right, it's just being slow to render it
Comment 3 Jesse Glick 2006-05-27 00:53:13 UTC
This or some similar 100%-CPU bug seems to affect maybe 1 in 20 of the PDF/PS
files I open (evince-0.5.1-3 on FC5).
Comment 4 Jakob Unterwurzacher 2008-02-14 05:45:11 UTC
Bug is still there - evince 2.20.1 / poppler 0.6 (cairo) on Ubuntu Gutsy.
So this probably is not limited to the Splash backend?
Comment 5 Albert Astals Cid 2009-06-17 13:05:56 UTC

*** This bug has been marked as a duplicate of bug 13518 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.