evince crashes while trying to print

Bug #157797 reported by Berthold Bollinger on 2007-10-27
10
Affects Status Importance Assigned to Milestone
Poppler
Fix Released
Medium
evince (Ubuntu)
Low
Ubuntu Desktop Bugs
poppler (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: evince

When i try to print certain pdf files, evince will crash and terminate itself. Other pdf files can be printed. I use a HP Laserjet 1018 with the foo2zjs driver, which works well. I can print the questionable pdf files using e.g. KPDF.
Moreover, when trying to view one of these pdf documents with evince started from firefox, evince would freeze.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 27 18:24:07 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/evince
NonfreeKernelModules: nvidia
Package: evince 2.20.0-0ubuntu3
PackageArchitecture: i386
ProcCmdline: evince file:///home/berthold/Desktop/kerner010607
ProcCwd: /home/berthold
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: evince
Uname: Linux berthold-desktop 2.6.22-14-386 #1 Sun Oct 14 22:36:54 GMT 2007 i686 GNU/Linux

Sebastien Bacher (seb128) wrote :

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

Changed in evince:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete

I tried to follow the debug instructions from the wiki and attached the result. By the way, this time evince did not terminate, but freeze.

This ist one of the pdf files evince cannot print. As it is a document published on the web, you can try it yourself:
http://www.zdf.de/ZDF/download/0,5587,7000979,00.pdf

Chris Conway (cconway) wrote :

I am having the same problem. Clicking "File -> Print" or pressing Ctrl-P causes evince to freeze. It stops accepting input and stops refreshing its own window. Sometimes the Print dialog appears (also frozen) and sometimes it doesn't. This started only in the last few days and is consistent across all PDFs and Postscript files, including files I have previously printed successfully. I recently upgraded libpoppler and libcairo via Software Update. I will be happy to provide a GDB dump if anyone can tell me how to trap a "frozen" rather than a "crashed" backtrace.

Panayiotis Karabassis (panayk) wrote :

The above file (http://www.zdf.de/ZDF/download/0,5587,7000979,00.pdf) starts printing normally on my computer.
However the following pdf causes evince to crash:

http://www.cs.berkeley.edu/~vazirani/algorithms/all.pdf

(I can print it from HPLIP Toolbox.)

I attach the log from gdb, and since this is a segmentation fault, the log from valgrind.

Panayiotis Karabassis (panayk) wrote :
Panayiotis Karabassis (panayk) wrote :

After running gdb again with debug information for libfreetype and libcairo, it seems SIGSEGV is received at line 39 of freetype-2.3.5/src/base/fttype1.c in FT_Get_PS_Font_Info:

39 FT_FACE_FIND_SERVICE( face, service, POSTSCRIPT_INFO );

At this point "face" looks like this:

(gdb) print *face
$1 = {num_faces = -11075584, face_index = 6684672, face_flags = -11599872, style_flags = 6684672, num_glyphs = -11730944,
  family_name = 0x660000 <Address 0x660000 out of bounds>, style_name = 0xff4a0000 <Address 0xff4a0000 out of bounds>,
  num_fixed_sizes = 6684672, available_sizes = 0xff430000, num_charmaps = 7012352, charmaps = 0xff3f0000, generic = {data = 0x700000,
    finalizer = 0xff3f0000}, bbox = {xMin = 8060928, yMin = -12648448, xMax = 12779520, yMax = -7405568}, units_per_EM = 0, ascender = 195,
  descender = 0, height = 3, max_advance_width = 0, max_advance_height = 195, underline_position = 0, underline_thickness = 32,
  glyph = 0xc10000, size = 0x6a0000, charmap = 0x8b0000, driver = 0x6a0000, memory = 0x680000, stream = 0x6a0000, sizes_list = {head = 0x560000,
    tail = 0x4f0000}, autohint = {data = 0x560000, finalizer = 0x350000}, extensions = 0x560000, internal = 0x1b0000}

This is what the same command returns during previous (successful) invocations of FT_Get_PS_Font_Info:

(gdb) print *face
$1 = {num_faces = 1, face_index = 0, face_flags = 2577, style_flags = 0, num_glyphs = 11,
  family_name = 0xb3a31d98 "NMUXUY+NewCenturySchlbk-Roman", style_name = 0xb3c252e8 "Roman", num_fixed_sizes = 0,
  available_sizes = 0x0, num_charmaps = 2, charmaps = 0xb3a2b1e8, generic = {data = 0x0, finalizer = 0}, bbox = {
    xMin = -217, yMin = -302, xMax = 1188, yMax = 1165}, units_per_EM = 1000, ascender = 1165, descender = -302,
  height = 1467, max_advance_width = 0, max_advance_height = 1467, underline_position = -100,
  underline_thickness = 50, glyph = 0xb3c3e7c0, size = 0xb3c3e8a0, charmap = 0xb3c3afd8, driver = 0xb3cf9848,
  memory = 0xb3c376d8, stream = 0xb3c3a050, sizes_list = {head = 0xb3a256a0, tail = 0xb3a256a0}, autohint = {
    data = 0x0, finalizer = 0}, extensions = 0x0, internal = 0xb3a34a90}

So it seems to me like the crash is due to FT_Get_PS_Font_Info being called with illegal (garbage) arguments from libcairo. I couldn't get debug information to show for the calling function in libcairo (I am probably doing something wrong) but " grep FT_Get_PS_Font_Info . -drecurse" says there is just one file that contains occurrences of FT_Get_PS_Font_Info in libcairo: cairo-type1-subset.c

There are two calls of FT_Get_PS_Font_Info there and in both cases "face" is constructed through an invocation of "_cairo_ft_unscaled_font_lock_face".

Pedro Villavicencio (pedro) wrote :

is this still an issue?

Panayiotis Karabassis (panayk) wrote :

After a quick test, yes.
I get "cairo context error: NULL pointer" in the terminal about 30 times, then a segmentation fault.

libcairo2: 1.4.10-1ubuntu4.4
evince: 2.20.1-0ubuntu1

Download full text (9.3 KiB)

The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/evince/+bug/207341

"Binary package hint: evince

Crash trying to print attached PDF, two pages per sheet, 600dpi.
Btw, it takes quite a long time, CPU goes to 100%, and the crash happens after a couple of minutes on my machine.
Trying to print again, even at 300dpi, always results in another crash, so I believe it's always reproducible.

http://launchpadlibrarian.net/12907877/inferenza-fol.pdf
# PDF that triggers the crash when printed 2 pages per sheet (421.4 KiB, application/pdf)

#0 ft_glyphslot_free_bitmap (slot=0xb0948c82)
    at /build/buildd/freetype-2.3.5/freetype-2.3.5/src/base/ftobjs.c:247
No locals.
#1 0x4ce73590 in FT_Load_Glyph (face=0x8f9bcd0, glyph_index=34, load_flags=522)
    at /build/buildd/freetype-2.3.5/freetype-2.3.5/src/base/ftobjs.c:298
 error = <value optimized out>
 driver = <value optimized out>
 hinter = <value optimized out>
#2 0x4acd5782 in _cairo_ft_scaled_glyph_init (abstract_font=0x90a4938, scaled_glyph=0x900f180,
    info=CAIRO_SCALED_GLYPH_INFO_METRICS) at /build/buildd/cairo-1.5.14/src/cairo-ft-font.c:2159
 fs_metrics = {x_bearing = 7.334742848667577e-316, y_bearing = -0.084837376325584024,
  width = 1.8032359957465722e+61, height = 2.0371159593266614e-312, x_advance = 5.9287877500949585e-323,
  y_advance = 841.5968728374512}
 scaled_font = <value optimized out>
 unscaled = (cairo_ft_unscaled_font_t *) 0x8ee0ca8
 glyph = <value optimized out>
 face = (FT_Face) 0x8f9bcd0
 error = <value optimized out>
 load_flags = 522
 x_factor = 0.084837376325584024
 y_factor = 0
 vertical_layout = 0
 status = CAIRO_STATUS_SUCCESS
#3 0x4ac9e2bc in _cairo_scaled_glyph_lookup (scaled_font=0x90a4938, index=34,
    info=CAIRO_SCALED_GLYPH_INFO_METRICS, scaled_glyph_ret=0xb7e45c6c)
    at /build/buildd/cairo-1.5.14/src/cairo-scaled-font.c:1809
 status = <value optimized out>
 key = {hash = 34, size = 2943}
 scaled_glyph = (cairo_scaled_glyph_t *) 0x900f180
 need_info = <value optimized out>
#4 0x4ac9f6d5 in _cairo_scaled_font_glyph_device_extents (scaled_font=0x90a4938, glyphs=0x8e3e528,
    num_glyphs=14, extents=0xb7e45cb0) at /build/buildd/cairo-1.5.14/src/cairo-scaled-font.c:1208
 scaled_glyph = (cairo_scaled_glyph_t *) 0x0
 x = -1209770816
 y = 132
 i = 0
#5 0x4acaf06e in _cairo_analysis_surface_show_glyphs (abstract_surface=0x8d94590, op=CAIRO_OPERATOR_OVER,
    source=0x86370b8, glyphs=0x8e3e528, num_glyphs=14, scaled_font=0x90a4938)
    at /build/buildd/cairo-1.5.14/src/cairo-analysis-surface.c:569
 surface = <value optimized out>
 status = 150584528
 backend_status = CAIRO_STATUS_SUCCESS
 extents = {x = 0, y = 0, width = 595, height = 841}
 glyph_extents = {x = 143986516, y = 0, width = 41316, height = 136573}
#6 0x4aca12af in _cairo_surface_show_glyphs (surface=0x8d94590, op=CAIRO_OPERATOR_OVER, source=0x909cb44,
    glyphs=0x8e3e528, num_glyphs=14, scaled_font=0x90a4938)
    at /build/buildd/cairo-1.5.14/src/cairo-surface.c:2139
 font_options = <value optimized out>
 dev_ctm = {xx = 1.1310237566022765e-311, yx = 3.3951932656432488e-313, xy = 2.8980733117991295e-309,
  yy = 2.2542569966026837e+52, x0 = 4.898451237867254e-266, y0 = ...

Read more...

valgrind reports:
==13745== Invalid read of size 4
==13745== at 0x51BE572: FT_Load_Glyph (ftobjs.c:549)
==13745== by 0x4A24921: _cairo_ft_scaled_glyph_init (cairo-ft-font.c:1922)
==13745== by 0x4A117AB: _cairo_scaled_glyph_lookup (cairo-scaled-font.c:1674)
==13745== by 0x4A12A5A: _cairo_scaled_font_glyph_device_extents (cairo-scaled-font.c:1124)
==13745== by 0x4A21ECD: _cairo_analysis_surface_show_glyphs (cairo-analysis-surface.c:516)
==13745== by 0x4A144DC: _cairo_surface_show_glyphs (cairo-surface.c:2086)
==13745== by 0x4A1FCC8: _cairo_meta_surface_replay_internal (cairo-meta-surface.c:816)
==13745== by 0x4A214B1: _paint_page (cairo-paginated-surface.c:299)
==13745== by 0x4A2171E: _cairo_paginated_surface_show_page (cairo-paginated-surface.c:445)
==13745== by 0x4A14BDF: cairo_surface_show_page (cairo-surface.c:1702)
==13745== by 0x49FF661: cairo_show_page (cairo.c:2155)
==13745== by 0xA267D97: pdf_document_file_exporter_end_page(_EvFileExporter*) (ev-poppler.cc:1753)
==13745== Address 0x55c5630 is 88 bytes inside a block of size 552 free'd
==13745== at 0x402269C: free (vg_replace_malloc.c:326)
==13745== by 0x51B7ABC: ft_free (ftsystem.c:158)
==13745== by 0x51BB319: ft_mem_free (ftutil.c:171)
==13745== by 0x51BC318: destroy_face (ftobjs.c:856)
==13745== by 0x51BC3B2: FT_Done_Face (ftobjs.c:1972)
==13745== by 0x4363704: CairoFont::~CairoFont() (CairoFontEngine.cc:251)
==13745== by 0x436401D: CairoFontEngine::getFont(GfxFont*, XRef*) (CairoFontEngine.cc:335)
==13745== by 0x4366915: CairoOutputDev::updateFont(GfxState*) (CairoOutputDev.cc:318)
==13745== by 0x5093BF1: Gfx::opShowText(Object*, int) (Gfx.cc:3073)
==13745== by 0x508F901: Gfx::execOp(Object*, Object*, int) (Gfx.cc:726)
==13745== by 0x50906FF: Gfx::go(int) (Gfx.cc:594)
==13745== by 0x5090C96: Gfx::display(Object*, int) (Gfx.cc:557)
==13745==

which looks like poppler has called FT_Done_Face on a live cairo_font_face_t.

Created an attachment (id=15501)
Do not call FT_Done_Face on a live cairo_font_t.

Pushed to both master and poppler-0.8 branch. Thanks!

Václav Šmilauer (eudoxos) wrote :

Confirming, while trying to print http://mech.fsv.cvut.cz/homeworks/student/SM3-I2-1/test2_ukazka.pdf (same for printing to file or printer).

Same result as Panayiotis for the other files (http://www.zdf.de/ZDF/download/0,5587,7000979,00.pdf prints fine, http://www.cs.berkeley.edu/~vazirani/algorithms/all.pdf crashes evince).

Fully up-to-date hardy (release).

libcairo2 1.6.0-0ubuntu1
evince 2.22.1.1-0ubuntu1
(on amd64)

Behdad Esfahbod from the freetype project pointed me to the poppler bug report, the issue being that 'poppler has called FT_Done_Face on a live cairo_font_face_t'.
The problem seems to be fixed in poppler 0.8.1 - I can confirm that with manually installing poppler from http://poppler.freedesktop.org/poppler-0.8.1.tar.gz and rebuilding evince, printing for all mentioned documents works.

Changed in evince:
status: Incomplete → Confirmed
Changed in poppler:
status: Unknown → Fix Released
Pedro Villavicencio (pedro) wrote :

fixed upstream then, thanks for the help!

Changed in poppler:
status: Confirmed → Fix Committed
Johan Christiansen (johandc) wrote :

This isn't fixed in Ubuntu Yet. We need a SRU fix for hardy. Perhaps the 0.8.2 packages from intrepid will work on hardy?

Sebastien Bacher (seb128) wrote :

that's not an evince bug

Changed in evince:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Invalid
Sebastien Bacher (seb128) wrote :

the new version is available in intrepid, closing the bug, could be a candidate for an hardy backport if somebody wants to try to apply the change to the hardy version

Changed in poppler:
status: Fix Committed → Fix Released
Changed in poppler:
importance: Unknown → Medium
Changed in poppler:
importance: Medium → Unknown
Changed in poppler:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.