Bug 4135 - Cairo Xlib backend fails when the path contains too many elements.
Summary: Cairo Xlib backend fails when the path contains too many elements.
Status: RESOLVED DUPLICATE of bug 10672
Alias: None
Product: cairo
Classification: Unclassified
Component: xlib backend (show other bugs)
Version: 1.0.2
Hardware: x86 (IA32) Linux (All)
: high minor
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
Keywords: have-backtrace
Depends on:
Reported: 2005-08-18 14:37 UTC by Vytas
Modified: 2007-08-14 06:50 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Testcase for the bug, sorry, that I've just pasted it in the report at first. (1.67 KB, text/plain)
2005-08-18 14:49 UTC, Vytas
My test program (1.25 KB, text/plain)
2005-11-22 00:26 UTC, Emmanuel Pacaud
backtrace with NBR=20000 (3.17 KB, text/plain)
2005-11-22 00:28 UTC, Emmanuel Pacaud
fails with n is large (2.47 KB, text/plain)
2006-06-16 11:29 UTC, Simon E Ching

Description Vytas 2005-08-18 14:37:37 UTC
Described above. At my system, it fails when I use self-defined method
koch_sala(cr, 4), that means approx. Every level of the second (integer)
parameter increases the number of points in the path by the magnitude of 7.

Simple GTK+ 2.8 program used:

/*breaks with messages like 'Fatal IO error 104 (Connection reset by peer) on X
server :0.0', especially when sized or maximized.*/
#include <gtk/gtk.h>

koch_sala_elementas(cairo_t* cr, double stx, double sty, int n)
	if (n > 0)
		stx = stx/ 4;
		sty = sty/ 4;
		koch_sala_elementas(cr, stx, sty, n);
		koch_sala_elementas(cr, sty, -stx, n);
		koch_sala_elementas(cr, stx, sty, n);
		koch_sala_elementas(cr, -2*sty, 2*stx, n);
		koch_sala_elementas(cr, stx, sty, n);
		koch_sala_elementas(cr, sty, -stx, n);
		koch_sala_elementas(cr, stx, sty, n);
		cairo_rel_line_to(cr, stx, sty);
		cairo_rel_line_to(cr, sty, -stx);
		cairo_rel_line_to(cr, stx, sty);
		cairo_rel_line_to(cr, -2*sty, 2*stx);
		cairo_rel_line_to(cr, stx, sty);
		cairo_rel_line_to(cr, sty, -stx);
		cairo_rel_line_to(cr, stx, sty);

koch_sala(cairo_t* cr, int n)
	cairo_move_to(cr, 0.2, 0.2);
	koch_sala_elementas(cr, 0.1, 0, n);
	koch_sala_elementas(cr, 0, 0.1, n);
	koch_sala_elementas(cr, -0.1, 0, n);
	koch_sala_elementas(cr, 0, -0.1, n);

expose(GtkWidget *widget, GdkEventExpose *event, gpointer data)
	cairo_t* cr = gdk_cairo_create(widget-> window);
	cairo_scale(cr, widget->allocation.width, widget->allocation.height);
	cairo_set_line_width (cr, 0.02);
	koch_sala(cr, 4);
	return TRUE;

int main (int argc, char **argv)
	gtk_init(&argc, &argv);
	GtkWidget *win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
	g_signal_connect(win, "delete_event", gtk_main_quit, NULL);
	GtkWidget* area = gtk_drawing_area_new(); 
	gtk_widget_set_size_request (area, 200, 200);
	g_signal_connect(G_OBJECT(area), "expose_event", G_CALLBACK(expose), NULL);
	gtk_container_add(GTK_CONTAINER(win), area);
	return 0;
Comment 1 Vytas 2005-08-18 14:49:06 UTC
Created attachment 2918 [details]
Testcase for the bug, sorry, that I've just pasted it in the report at first.
Comment 2 Owen Taylor 2005-08-21 12:30:22 UTC
I'm confused here:
 - The code in libXrender just truncates the request to fit within
   the server's maximum request size; so it should just misdraw
   when you exceed that, and not get killed by the X server.
   (It's pretty big - I have to up level to 6 to exceed the size 
   on my X server)

 - I have no problems with the 'Xfake' server from the X server tree
 - But I do reproduce the problem with my main X server (a 6 month
   old X.org snapshot) - at sizes less than the maximum request size; 
   no truncation at all. Unfortunately, it's much harder to debug that, 
   though I'll try tomorrow when I get into work and have a second computer,
   hopefully I still have debug symbols for this server.
Comment 3 Carl Worth 2005-08-22 17:15:03 UTC
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
Comment 4 Emmanuel Pacaud 2005-11-22 00:25:56 UTC
I'm also experiencing this bug. 

Please find attached my sample test programm, which is basically the same as
Vytas, and, more important, a backtrace.

I'm using ubuntu breezy, which ships xorg 6.8.2.
Comment 5 Emmanuel Pacaud 2005-11-22 00:26:44 UTC
Created attachment 3861 [details]
My test program
Comment 6 Emmanuel Pacaud 2005-11-22 00:28:32 UTC
Created attachment 3862 [details]
backtrace with NBR=20000
Comment 7 Vytas 2005-11-22 01:37:06 UTC
Changed version to 1.0.2 (Cairo 1.0.2 is used on Ubuntu 5.10)

I've tested my program on Ubuntu 5.10, too. The issue remains, as reported by
I simple get it disconnected by X server:

The application 'fractals' lost its connection to the display :0.0;
most likely the X server was shut down or you killed/destroyed
the application.

Comment 8 Simon E Ching 2006-06-16 11:25:26 UTC
I experienced this problem since one year ago.  The bug showed up on my
Powerbook (using Apple's X11) but not on my Slackware Linux box running XFree86.
 Now I've acquired a new computer running Xorg on a Gentoo Distribution and this
bug creeped up.  I am too lazy to reinstall XFree86 just for the sake of testing
(I am not a developer of cairo afterall ^_^) so I would encourage anyone running
a XFree86 to test for this bug.  And I hope this extra information helps.

I have another test program I just wrote up to demostrate this problem.  Quite
unexpectedly, while I reckon of its relatively lightness, cairo_stroke is less
tolerate of the size of the path.  For my test program, the program failed in
cairo_stroke with n > 14624, while it failed in cairo_fill when n > 209864.

Please see the attachment for the test case (the png backend, as a control case,
runs perfectly)
Comment 9 Simon E Ching 2006-06-16 11:29:00 UTC
Created attachment 5940 [details]
fails with n is large

fails when n > 14624 for cairo_stroke and n > 209864 for cairo_fill
Comment 10 Chris Wilson 2007-08-14 04:54:24 UTC

*** This bug has been marked as a duplicate of bug 10672 ***
Comment 11 Emmanuel Pacaud 2007-08-14 06:45:48 UTC
Chris, I don't understand the relationship with #10672.

If #10672 is fixed, does that mean a big path will be correctly stroked ?

If not, that means this bug is not a duplicate of #10672.
Comment 12 Chris Wilson 2007-08-14 06:50:00 UTC
Sadly 10672 just contains a fix for the Xserver to accept the large requests triggered by long paths - it has yet to be applied.

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.