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) { n--; 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); } else { 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); cairo_close_path(cr); cairo_fill(cr); } 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); cairo_show_page(cr); cairo_destroy(cr); 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); gtk_widget_show_all(win); gtk_main(); return 0; }
Created attachment 2918 [details] Testcase for the bug, sorry, that I've just pasted it in the report at first.
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.
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
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.
Created attachment 3861 [details] My test program
Created attachment 3862 [details] backtrace with NBR=20000
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 Emmanuel. 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.
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)
Created attachment 5940 [details] fails with n is large fails when n > 14624 for cairo_stroke and n > 209864 for cairo_fill
*** This bug has been marked as a duplicate of bug 10672 ***
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.
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.