Bug 536518 – Crash after refreshing a pdf (with std::out_of_range)

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 536518 - Crash after refreshing a pdf (with std::out_of_range)


Summary:	Crash after refreshing a pdf (with std::out_of_range)


Status:	RESOLVED NOTGNOME

Product:	evince
Classification:	Core
Component:	PDF
Version:	2.22.x
Hardware:	Other All

Importance:	Normal critical
Target Milestone:	---
Assigned To:	Evince Maintainers
QA Contact:	Evince Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2008-06-03 22:17 UTC by Eric Piel
Modified:	2008-06-05 21:09 UTC

See Also:
GNOME target:	---
GNOME version:	2.21/2.22

Description Eric Piel 2008-06-03 22:17:32 UTC

Steps to reproduce:
1. Open a pdf file that you have done yourself (eg: openoffice, pdflatex)
2. Move around the document
3. Modify the document and regenerate the pdf
4. Move around the document until the page is white (not sure if it's needed)
5. Refresh the document
6. Goto 2
After a couple of repetition, it crashes.


Stack trace:
Sorry, for tonight I only have this log, I'll try to get a full stack trace from a debug-enabled evince tomorrow.

evince: xcb_lock.c:77: _XGetXCBBuffer: Controletest '((int) ((xcb_req) - (dpy->request)) >= 0)' faalt.
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check

[1]+  Segmentatiefout 

Other information:
This happens both on 64bits and 32bits x86.

I think the crash sometimes happens even while reading other pdf documents, the common point being that I've refreshed a PDF file.

I mention PDF files because that's what I use only, but it doesn't mean it's not happening with other formats.

This seems to happen only since a couple of months (maybe since my xlib uses xcb?).

Comment 1 Eric Piel 2008-06-03 22:42:26 UTC

Here is a back trace obtain on x86-64 (it's a SIGBUS here probably because the kernel detect the memory corruption in a different way):

Program received signal SIGBUS, Bus error.

+ Trace 199524

Thread 1101330768 (LWP 486612)

#0 FT_Done_Face
from /usr/lib64/libfreetype.so.6
#1 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#2 cairo_font_face_destroy
from /usr/lib64/libcairo.so.2
#3 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#4 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#5 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#6 cairo_scaled_font_destroy
from /usr/lib64/libcairo.so.2
#7 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#8 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#9 cairo_set_font_face
from /usr/lib64/libcairo.so.2
#10 CairoOutputDev::updateFont
from /usr/lib64/libpoppler-glib.so.3
#11 Gfx::opShowSpaceText
from /usr/lib64/libpoppler.so.3
#12 Gfx::go
from /usr/lib64/libpoppler.so.3
#13 Gfx::display
from /usr/lib64/libpoppler.so.3
#14 Page::displaySlice
from /usr/lib64/libpoppler.so.3
#15 g_cclosure_marshal_VOID__ENUM
at gmarshal.c line 334
#16 poppler_page_render_to_pixbuf
from /usr/lib64/libpoppler-glib.so.3
#17 pdf_document_thumbnails_get_thumbnail
at ev-poppler.cc line 1263
#18 ev_job_thumbnail_run
at ev-jobs.c line 468
#19 handle_job
at ev-job-queue.c line 129
#20 ev_render_thread
at ev-job-queue.c line 264
#21 g_thread_create_proxy
at gthread.c line 635
#22 start_thread
from /lib64/libpthread.so.0
#23 clone
from /lib64/libc.so.6

Comment 2 Nickolay V. Shmyrev 2008-06-04 07:29:18 UTC

Hi, this looks like a bug with the PDF backend.  Could you please follow these instructions to help get this bug fixed.  Thank You. 

http://live.gnome.org/Evince/PopplerBugs#poppler

Comment 3 Eric Piel 2008-06-05 11:21:42 UTC

Moved to poppler there:
https://bugs.freedesktop.org/show_bug.cgi?id=16236

Comment 4 Nickolay V. Shmyrev 2008-06-05 21:09:09 UTC

Thanks a lot!