evince hangs eating CPU when rendering a pdf page

I believe gpdf has been depercated in favour of evince but looking at page 13 on my machine causes evince to go into a CPU hogging loop:

Steps to reproduce:
1. Download http://www.mises.org/etexts/cwik-dissertation.pdf
2. Open the downloaded file in evince .
3. Type 13 in the page box at the top of the window and press return.

Expected results:
Page 13 to be displayed after a few seconds.

Actual results:
Evince goes to page 13 but continues to display it Loading... message while chewing up all the CPU it can get for minutes on end.

Additional information:
acroread displays the page incrementally and after 5 seconds the entire page is finished.

I forgot to mention my tests were on:
evince 0.5.2-0ubuntu1
libpoppler1 0.5.1-0ubuntu5
libpoppler1-glib 0.5.1-0ubuntu5
poppler-utils 0.5.1-0ubuntu5

Sorry, I cannot replicate on Dapper with the same versions of Evince. Can you get a backtrace on evince?

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, d...

It might be interesting to get a backtrace of evince with a debug build of poppler. Can you do that? http://wiki.ubuntu.com/DebuggingProgramCrash has information on that.

Daniel,

I'm sorry but I can't give you a debug symbol backtrace unless someone provides me with the appropriate dbg packages. My dapper system as it stands simply doesn't have the room for a toolchain (it's a test setup on a small 4Gbyte disk that is practically full already) so I can't build them for myself. (If only Ubuntu had dbg packages for everything like Fedora does...) Sorry...

Kevin:
Any chance that you could rebuild the packages with the appropriate debug symbols and reproduce the crash?

Alas, I have no idea how to do that. Perhaps if you walk me through it?

I've forwarded the issue upstream: https://bugs.freedesktop.org/show_bug.cgi?id=6680

(still here in edgy:
evince 0.6.1-0ubuntu1
libpoppler1 0.5.4-0ubuntu4
libpoppler1-gl 0.5.4-0ubuntu4
poppler-utils 0.5.4-0ubuntu4
)

Still here:

Version Information:
Ubuntu Feisty (Herd 5)
evince 0.7.2-0ubuntu2
libpoppler1 0.5.4-0ubuntu5
libpoppler1-glib
poppler-utils

Still here:

Ubuntu Gutsy
evince 2.20.1-0ubuntu1
libpoppler-glib2 0.6-0ubuntu2.1

Confirm. Evince bacame a memory hog. It eats all possible memory and hangs.
Evince 2.22.2
poppler 0.6.4 (cairo)

CORRECTION. Evince hangs opening all files in MAXIMIZED window mode.

how did it go from confirmed to invalid with no explanation?

Happening to me on a djvu file. Going up to 85% cpu usage and taking more than 20 seconds to render it.
evince 2.26.2

Kevin Fisher, the document is not available via the URL in the Bug Description. Hence, could you please provide an example document that demonstrates this problem?