GNOME Bugzilla – Bug 732737
Long string values can crash editor
Last modified: 2018-04-15 00:06:57 UTC
Created attachment 279898 [details] [review] Ellipsize string values Keys with long string values can cause problems with allocation of memory for the Gtk.CellRendererText which shows the values in dconf-editor. I've observed a crash caused by this on virtual machines (it is probably related to amount of video memory). Ellipsizing solves the problem for me. Attached is a patch which ellipsize the text renderer. Marek
I put a 50MB string into dconf and this is 100% reproducible. I don't get an outright crash, though -- rather just an extremely long computation. This is surely either a gtk or pango bug... Here's a backtrace from some randomly chosen point:
+ Trace 233771
After a while churning at that, we get this output: (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkButton': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `DConfKeyView': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkScrolledWindow': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkVBox': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkHPaned': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkBox': invalid value (typically too big) for the size of the input (surface, pattern, etc.) (dconf-editor:15561): Gtk-WARNING **: drawing failure for widget `GtkApplicationWindow': invalid value (typically too big) for the size of the input (surface, pattern, etc.) and then the display looks like (attached).
Created attachment 279928 [details] picture of the problem
Marek: what/how-big was the original string in there? (to avoid the inevitable arguments about if Gtk should really try to cater to people shoving unreasonable things into labels...)
(In reply to comment #4) > Marek: what/how-big was the original string in there? (to avoid the > inevitable arguments about if Gtk should really try to cater to people shoving > unreasonable things into labels...) Unfortunately, I can not reproduce it right now (I'll try it tomorrow in the office). But I think that the string was about 50000 characters long. I have to admit that this was on Fedora 20 which doesn't have latest gtk+/pango/cairo.
It doesn't crash for me with current gtk+ (3.13.3). I've tracked down the commit which change that and it is this one: https://git.gnome.org/browse/gtk+/commit/?id=aa339ee30ca1420217e772ce3a5eedb507bf9d67. I've tried to place the linear gradients back to the "column-header" and it started to crash again. The error is: (dconf-editor:14655): Gdk-ERROR **: The program 'dconf-editor' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 4041 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) and backtrace from valgrind is: ==14655== Process terminating with default action of signal 5 (SIGTRAP) ==14655== at 0x3962A504E9: g_logv (gmessages.c:989) ==14655== by 0x3962A5063E: g_log (gmessages.c:1025) ==14655== by 0x56C504E: _gdk_x11_display_error_event (gdkdisplay-x11.c:2557) ==14655== by 0x56D0219: gdk_x_error (gdkmain-x11.c:303) ==14655== by 0x39646450BA: _XError (XlibInt.c:1463) ==14655== by 0x39646420B6: handle_error (xcb_io.c:213) ==14655== by 0x3964642174: handle_response (xcb_io.c:325) ==14655== by 0x39646430FF: _XReply (xcb_io.c:627) ==14655== by 0x396463EA2C: XSync (Sync.c:44) ==14655== by 0x396463EACA: _XSyncFunction (Synchro.c:35) ==14655== by 0x3964645A0E: _XPrivSyncFunction (XlibInt.c:251) ==14655== by 0x3964E08ED2: XShmCreatePixmap (XShm.c:429) ==14655== by 0x396C6A2F63: _cairo_xlib_shm_surface_create.isra.10 (cairo-xlib-surface-shm.c:842) ==14655== by 0x396C6A33E6: _cairo_xlib_surface_create_shm (cairo-xlib-surface-shm.c:1155) ==14655== by 0x396C6A347B: _cairo_xlib_surface_create_similar_shm (cairo-xlib-surface-shm.c:1180) ==14655== by 0x396C67083C: cairo_surface_create_similar_image (cairo-surface.c:593) ==14655== by 0x396C670A07: cairo_surface_create_similar (cairo-surface.c:518) ==14655== by 0x4F85BE7: _gtk_css_image_get_surface (gtkcssimage.c:400) ==14655== by 0x4F10E2C: _gtk_border_image_render (gtkborderimage.c:258) ==14655== by 0x518EB39: render_frame_internal (gtkthemingengine.c:1736) ==14655== by 0x518F0A0: gtk_theming_engine_render_frame (gtkthemingengine.c:1786) ==14655== by 0x512DFC9: gtk_render_frame (gtkstylecontext.c:4012) ==14655== by 0x4F26A7B: gtk_button_draw (gtkbutton.c:1857) ==14655== by 0x5054DA3: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130) ==14655== by 0x5204045: gtk_widget_draw_marshallerv (gtkwidget.c:1009) ==14655== by 0x396361043E: _g_closure_invoke_va (gclosure.c:840) ==14655== by 0x3963629748: g_signal_emit_valist (gsignal.c:3238) ==14655== by 0x396362A3AE: g_signal_emit (gsignal.c:3386) ==14655== by 0x520DF30: _gtk_widget_draw_internal (gtkwidget.c:6441) ==14655== by 0x520E435: _gtk_widget_draw (gtkwidget.c:6619) ==14655== by 0x4F7AAEA: gtk_container_propagate_draw (gtkcontainer.c:3528) ==14655== by 0x51DFA6C: gtk_tree_view_draw (gtktreeview.c:5513) I guess that if there are no linear-gradients then there is an optimization which allows gtk+ to create such big widget (316115 x 24 in this case). I'm not sure whether this is solvable since there is not enough memory. This is on a computer with integrated graphic card: Intel Corporation 82Q35 Express Integrated Graphics Controller.
Seems to be two separate issues here: Gtk behaves badly under the new theme with very large widgets, and badly in a different way with hilariously large widgets (even with the old theme).
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new