GNOME Bugzilla – Bug 755810
crash in Document Viewer: opening an eps file
Last modified: 2016-09-29 17:43:56 UTC
The file at http://in.terlu.de/~kreckel/add.eps produces a segmentation fault in evince 3.16.1.
Backtrace: Program received signal SIGSEGV, Segmentation fault. bits_image_fetch_separable_convolution_affine (repeat_mode=PIXMAN_REPEAT_NONE, format=PIXMAN_x8r8g8b8, convert_pixel=<optimized out>, mask=0x0, buffer=0xd7d010, width=<optimized out>, line=<optimized out>, offset=<optimized out>, image=0xcab300) at ../../pixman/pixman-fast-path.c:2813 2813 ../../pixman/pixman-fast-path.c: No such file or directory. (gdb) thread apply all bt
+ Trace 235501
Thread 1 (Thread 0x7ffff7fb8880 (LWP 3376))
So the traces look like a problem with either cairo or other underlying library used to render eps. Can you check versions and whether there are similar traces in their bugzillas?
Found nothing yet in a quick search. But isn't this trace pointing to libevview3? Program received signal SIGSEGV, Segmentation fault. INT_cairo_surface_set_device_scale (surface=0x0, x_scale=1, y_scale=1) at ../../../../src/cairo-surface.c:1686 1686 ../../../../src/cairo-surface.c: No such file or directory. (gdb) thread apply all bt
+ Trace 235534
Thread 1 (Thread 0x7ffff7fb9980 (LWP 3465))
(Referring to Debian's libevview3 3.14.1 package.)
oh, traces are different. yes, for some reason we are assuming that backends will always render a correct surface. that is not always the case. For your trace there is a patch in other bug I can't remember atm
(In reply to Germán Poo-Caamaño from comment #1) After upgrading to 3.18.0, I'm seeing your trace to the segfault in pixman-fast-path.c.
Which distribution are you using ? Could you please post pixman's version ?
To get line numbers correct, here is a new bt, created with pibpixman-1-0_0.33.3-2 from Debian testing: Program received signal SIGSEGV, Segmentation fault. bits_image_fetch_separable_convolution_affine (repeat_mode=PIXMAN_REPEAT_NONE, format=PIXMAN_x8r8g8b8, convert_pixel=<optimized out>, mask=0x0, buffer=0x7fffffff35c0, width=<optimized out>, line=<optimized out>, offset=<optimized out>, image=0x555555d85060) at ../../pixman/pixman-fast-path.c:2815
+ Trace 235538
I would like to suggest two things: 1. Open a bug on pixman in freedesktop.org bugzilla. That's where pixman contributes are looking, so it would get more responses. 2. I would try to install the previous pixman version, 0.32.6, and see if the bug reproduce and post the result to the bug. Oded
(In reply to Oded Gabbay from comment #9) > 1. Open a bug on pixman in freedesktop.org bugzilla. That's where pixman > contributes are looking, so it would get more responses. https://bugs.freedesktop.org/show_bug.cgi?id=92210 > 2. I would try to install the previous pixman version, 0.32.6, and see if > the bug reproduce and post the result to the bug. Reproduced in 0.32.6, cf. bt in pixman bugreport.
"valgrind evince add.eps" says: ==26671== Thread 1: ==26671== Invalid read of size 4 ==26671== at 0xA7E98CB: convert_x8r8g8b8 (pixman-fast-path.c:3081) ==26671== by 0xA7F4271: bits_image_fetch_separable_convolution_affine (pixman-fast-path.c:2813) ==26671== by 0xA7F4271: bits_image_fetch_separable_convolution_affine_none_x8r8g8b8 (pixman-fast-path.c:3153) ==26671== by 0xA807E5F: general_composite_rect (pixman-general.c:209) ==26671== by 0xA61F93A: pixman_image_composite32 (pixman.c:707) ==26671== by 0x651E8AE: composite_boxes (cairo-image-compositor.c:538) ==26671== by 0x6571BE3: composite_aligned_boxes (cairo-spans-compositor.c:683) ==26671== by 0x657246C: clip_and_composite_boxes (cairo-spans-compositor.c:882) ==26671== by 0x6572807: _cairo_spans_compositor_paint (cairo-spans-compositor.c:983) ==26671== by 0x650E92F: _cairo_compositor_paint (cairo-compositor.c:65) ==26671== by 0x6528E8E: _cairo_image_surface_paint (cairo-image-surface.c:927) ==26671== by 0x657868C: _cairo_surface_paint (cairo-surface.c:2117) ==26671== by 0x657F4E1: _cairo_surface_offset_paint (cairo-surface-offset.c:85) ==26671== Address 0x255591c0 is 0 bytes after a block of size 3,121,536 alloc'd ==26671== at 0x4C28F00: malloc (vg_replace_malloc.c:296) ==26671== by 0x1CD350B6: spectre_presize (spectre-device.c:75) ==26671== by 0x1D1E657F: display_open (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1D373265: gs_opendevice (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1D0DA48B: display_set_callback (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1D0D6130: gs_main_init2aux (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1D0D65F0: gs_main_init2 (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1D0D93C7: gs_main_init_with_args (in /usr/lib64/libgs.so.9.15) ==26671== by 0x1CD348C4: spectre_gs_run (spectre-gs.c:190) ==26671== by 0x1CD35430: spectre_device_render (spectre-device.c:264) ==26671== by 0x1CD3580B: spectre_page_render (spectre-page.c:164) ==26671== by 0x1CB2DA6C: ps_document_render (in /usr/lib64/evince/4/backends/libpsdocument.so) Then setting breakpoints in gdb on 'spectre_presize' and 'cairo_image_surface_create_for_data' reveals the following: Breakpoint 1, spectre_presize (handle=0x7fffc8026a90, device=0x7fffc814c298, width=1055, height=739, raster=4224, format=6359172) at spectre-device.c:67 67 if (!handle) (gdb) Continuing. Breakpoint 2, INT_cairo_image_surface_create_for_data (data=0x7fffc75da010 "\377\377\377", format=CAIRO_FORMAT_RGB24, width=739, height=1055, stride=4224) at /usr/src/debug/x11-libs/cairo-1.14.2/cairo-1.14.2/src/cairo-image-surface.c:514 514 if (! CAIRO_FORMAT_VALID (format)) (gdb) Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7f928c0 (LWP 24493)] 0x00007ffff22218cb in convert_x8r8g8b8 (row=0x7fffc7974f90 "\230A ", x=0) at /usr/src/debug/x11-libs/pixman-0.32.8/pixman-0.32.8/pixman/pixman-fast-path.c:3081 3081 return *(((uint32_t *)row) + x); (gdb) Looks like 'width' and 'height' are just swapped somewhere. So that cairo and then pixman receive the image buffer of incorrect size and crash trying to access pixels, which had not been properly allocated.
My current guess is, that it happens in Evince’s `libview/ev-view.c` in the function below. ``` void _get_page_size_for_scale_and_rotation (EvDocument *document, gint page, gdouble scale, gint rotation, gint *page_width, gint *page_height) { gdouble w, h; gint width, height; ev_document_get_page_size (document, page, &w, &h); width = (gint)(w * scale + 0.5); height = (gint)(h * scale + 0.5); if (page_width) *page_width = (rotation == 0 || rotation == 180) ? width : height; if (page_height) *page_height = (rotation == 0 || rotation == 180) ? height : width; } ```
I can't tell because the link is returning a 404, but this is possibly the same as bug 755776 where the scaling calculations are bad for rotated PS documents. The scaling calculation should be fixed now, but it could still have other problems due to the interaction of libspectre and ghostscript.
For reference, here is the related bug report on freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=76450 (Freedesktop.org bugs 87588 and 92210 are duplicates of this one.)
The file add.eps is not available anymore. However, the bug reported in freedesktop was marked as duplicated of other ones as pointed in #c14. Original report: https://bugs.freedesktop.org/show_bug.cgi?id=92210 The documents attached in those documents do not make evince crash anymore with libspectre 0.2.8. So I am closing this bug as NOTGNOME
Hi, could you please also have a look at https://bugs.freedesktop.org/show_bug.cgi?id=96615 and try the test case from there?
Created attachment 336525 [details] Screenshot rendering test case The screenshot shows Evince displaying the document (not crashing) The test case from https://bugs.freedesktop.org/show_bug.cgi?id=96615
Indeed, this was fixed with libspectre 0.2.8: https://bugs.freedesktop.org/show_bug.cgi?id=76450
OK, thanks a lot. I guess, we can finally close all these bugreports now.