Bug 75705 - "double free or corruption" error appeares while i try to draw dotted line
Summary: "double free or corruption" error appeares while i try to draw dotted line
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.12.16
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: cairo-1.14
  Show dependency treegraph
 
Reported: 2014-03-03 11:25 UTC by Sergey Pevzner
Modified: 2018-08-25 13:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch adding two printfs calls highlighting the cause for the heap corruption (940 bytes, patch)
2014-03-03 19:01 UTC, Uli Schlachter
Details | Splinter Review
testcase (2.15 KB, patch)
2015-01-16 12:12 UTC, Massimo
Details | Splinter Review

Description Sergey Pevzner 2014-03-03 11:25:05 UTC
/*

"double free or corruption" error appeares while i try to draw dotted line

in case I comment line:

cairo_set_line_cap(cr, CAIRO_LINE_CAP_ROUND);

or change antialias type to CAIRO_ANTIALIAS_BEST

- all work properly

*/

#include<cstdio>
#include<cairo/cairo.h>

int main()
{
	cairo_surface_t *surface;
	cairo_t *cr;
	surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 256, 256);
	cr = cairo_create(surface);

	cairo_set_source_rgba(cr, 0, 0, 0, 1);
	cairo_paint(cr);
	
	cairo_set_line_cap(cr, CAIRO_LINE_CAP_ROUND);
	cairo_set_line_join(cr, CAIRO_LINE_JOIN_ROUND);

	cairo_new_path(cr);

	cairo_move_to(cr, 100, 251);
	cairo_line_to(cr, 100, 196);
	
	cairo_move_to(cr, 36, 3);
	cairo_line_to(cr, 107, 3);

	cairo_set_antialias(cr, CAIRO_ANTIALIAS_FAST);
	cairo_set_tolerance(cr, 1);
	
	double dsh[2] = {1,3};
	
	cairo_set_dash(cr, dsh, 2, 0);
	cairo_set_source_rgba(cr, 1, 1, 1, 1);
	cairo_set_line_width(cr, 2);
	
	cairo_stroke(cr);

	cairo_destroy (cr);
	cairo_surface_write_to_png (surface, "hello.png");
	cairo_surface_destroy (surface);
	
	return 0;
}
Comment 1 Uli Schlachter 2014-03-03 19:01:27 UTC
Created attachment 95052 [details] [review]
Patch adding two printfs calls highlighting the cause for the heap corruption

With the attached patch and running the test program under valgrind, we get the following output:

converter->spans allocated array of size 71
Using index 71
==15967== Invalid write of size 4
==15967==    at 0x4ED51E6: _cairo_tor22_scan_converter_generate (cairo-tor22-scan-converter.c:1443)
==15967==    by 0x4EC14BF: clip_and_composite_polygon (cairo-spans-compositor.c:801)
==15967==    by 0x4EC2106: _cairo_spans_compositor_stroke (cairo-spans-compositor.c:1083)
==15967==    by 0x4E61EFB: _cairo_compositor_stroke.part.0 (cairo-compositor.c:157)
[...]
==15967==  Address 0x8333638 is 0 bytes after a block of size 568 alloc'd
[...]
index used

So the tor22 scan converter reads one entry behind the converter's spans array.

Figuring out why this happens, turning this into a unit test for the test suite and checking if the other scan converters are affected, too, is left as an excercise for someone who knows more about this code.
Comment 2 Chris Wilson 2014-03-03 20:50:22 UTC
Oh it's trivial. This is how far I got this morning:

commit f620c1b24ba9a80518da22c579ada65582885c82
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 3 11:43:24 2014 +0000

    tor22: Fix off-by-one in allocation of spans
    
    The range [xmin, xmax] is inclusive and so requires xmax-xmin+1 slots.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75705
    Testcase:
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 3 Bryce Harrington 2014-09-16 19:00:42 UTC
Chris, I'm not finding your aforementioned patch anywhere; mind attaching it here?
Comment 4 Massimo 2015-01-15 07:25:51 UTC
Here a possible fix that seems to be in line with the commit message above
is to copy the first lines of the function 'glitter_scan_converter_reset'
from the file src/cairo-tor-scan-converter.c and paste them in the file
src/cairo-tor22-scan-converter.c so that their implementations match.
Comment 5 Massimo 2015-01-16 12:12:32 UTC
Created attachment 112338 [details] [review]
testcase

Apparently none of the tests in the test-suite exercises
tor22 scan converter, at least for the image backend.

Forcing CAIRO_ANTIALIAS_FAST and tolerance=1 to the context
before running the tests shows many tests would use tor22
scan converter, but no test crashes

This means that it is easier to add a new test based on the bug report
than to adapt an existing one. If you need a small image it is
sufficient the horizontal stroke, I've attached a patch as an example.
It is missing the license and copyright notice to let Sergey
choose it and receive the credit. 
The output is deliberately black on black, easy to get right for 
all backends.

BTW, according to grep, there is only another function named
glitter_scan_converter_reset (in src/cairo-clip-tor-scan-converter.c),
but it has a different signature and implementation: bugs there
would not be related to this report.
Comment 6 GitLab Migration User 2018-08-25 13:31:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/44.


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.