Bug 85151 - Segfault when loading a PDF with a transformed image (1.14.0)
Summary: Segfault when loading a PDF with a transformed image (1.14.0)
Alias: None
Product: cairo
Classification: Unclassified
Component: xlib backend (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
: 85591 (view as bug list)
Depends on:
Reported: 2014-10-17 16:34 UTC by Matthew Leach
Modified: 2014-10-29 09:18 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

problematic PDF file. (8.92 KB, application/pdf)
2014-10-17 16:34 UTC, Matthew Leach
Backtrace (36.94 KB, text/plain)
2014-10-17 16:35 UTC, Matthew Leach
problematic PDF file, 2. (2.44 KB, application/pdf)
2014-10-17 19:46 UTC, Matthew Leach
proposed patch (1.06 KB, patch)
2014-10-19 07:28 UTC, Massimo
Details | Splinter Review

Description Matthew Leach 2014-10-17 16:34:44 UTC
Created attachment 107995 [details]
problematic PDF file.


When opening a PDF file with evince that contains a transformed image file a segmentation fault occurs.  A back trace seems to indicate the problem is in cairo.  I've attached the PDF file that is causing the issue. It was generated with pdflatex, I can attach the TeX source if people require too.

This bug occurs with cairo 1.14.0
Comment 1 Matthew Leach 2014-10-17 16:35:49 UTC
Created attachment 107996 [details]

Full backtrace of the segmentation fault.
Comment 2 Matthew Leach 2014-10-17 19:46:14 UTC
Created attachment 108004 [details]
problematic PDF file, 2.

After doing some experimenting, I've found that rotating vector graphics also seems to provoke the bug.  Further, this bug seems to cause evince to crash sooner; I have to do less zooming in and out before evince crashes.
Comment 3 Massimo 2014-10-19 07:28:21 UTC
Created attachment 108052 [details] [review]
proposed patch

I reproduced the crash with test2.pdf and an evince built from    
git sources

$git --git-dir=evince/.git describe HEAD --long 3.14.1-0-gf1cda92
$git --git-dir=poppler/.git describe HEAD --long poppler-0.26.4-59-g745f124
$git --git-dir=cairo/.git describe HEAD --long 1.14.0-7-g51892e9

at 50% zoom.

Comparing my alternative solution to bug 84396 with that in master I recall 
that I noticed that full_row should be used only when there is no intersection 
in the current row and in the top half of the successive subrow, otherwise 
redundant (negative) spans are possibly generated when sub_row is called for
the next row and I observed a similar crash and backtrace.

The attached patch fixes the crash with test2.pdf, but I did not reproduce it
with test.pdf.
Comment 4 Matthew Leach 2014-10-19 11:30:10 UTC
I can confirm that the proposed patch does fix the issue that I was having.
Comment 5 Chris Wilson 2014-10-19 11:47:43 UTC
commit 2de69581c28bf115852037ca41eba13cb7335976
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Sun Oct 19 09:19:10 2014 +0200

    tor-scan-converter: can't do_fullrow when intersection in row + 0.5subrow
    the active edges list must be left sorted at the next possible use
    and since full_row does not deal with intersections it is not usable
    when there is an intersection in the top half of the next row first
    Reported-and-tested-by: Matthew Leach
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85151
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 6 Adrian Johnson 2014-10-29 09:18:15 UTC
*** Bug 85591 has been marked as a duplicate of this bug. ***

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.