GNOME Bugzilla – Bug 773814
attempt to allocate widget with width -700975964 and height 400
Last modified: 2017-05-08 22:03:47 UTC
Hello, I'm seeing a lot of these GTK+ warnings which come from what I believe might be a bug in GtkBox: Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -700975964 and height 400 I debugged the code a bit and I think the problem is here (I turned this into pseudocode for simplicity): ------------------------------------------------ gtk_box_size_allocate_no_center (GtkWidget *widget, const GtkAllocation *allocation) { GtkRequestedSize *sizes; sizes = g_newa (GtkRequestedSize, nvis_children); /* Retrieve desired size for visible children. */ for (i = 0, children = private->children; children; children = children->next) { if (!_gtk_widget_get_visible (child->widget)) continue; sizes[i] = gtk_widget_get_preferred_width_for_height(...); } /* Allocate child sizes. */ for (i = 0, children = private->children; children; children = children->next) { if (!_gtk_widget_get_visible (child->widget)) continue; child_allocation = sizes[i]; gtk_widget_size_allocate_with_baseline (child->widget, &child_allocation, baseline); } } ------------------------------------------------ So if a child is not visible we don't get its desired size (i.e. we leave sizes[i] uninitialized) but later we don't allocate its size either so that's not a problem. However allocating the size of a visible child emits "size-allocate", and its signal handler may end up showing a sibling that was previously hidden, causing its child_allocation to be based on an uninitialized sizes[i]. I found this with a GtkScrollbar that shows or hides itself after a GtkAdjustment::changed signal from a sibling widget inside the same container.
> However allocating the size of a visible child emits "size-allocate", > and its signal handler may end up showing a sibling that was > previously hidden This must not happen. Any code that does this is broken. during size_allocate, visibility of widgets in the widget tree must not be changed. We should probably initialize the sizes[i] = 0; for invisible widget as a workaround, so we'd not get this crazy warning. Also, uninitialized memory is bad.
(In reply to Benjamin Otte (Company) from comment #1) > > However allocating the size of a visible child emits > > "size-allocate", and its signal handler may end up showing a > > sibling that was previously hidden > This must not happen. Any code that does this is broken. during > size_allocate, visibility of widgets in the widget tree must not be > changed. As I said in my code it was not exactly during size_allocate but upon GtkAdjustment::changed. In the former case it looks intuitively like a bad idea, in the latter not so much. Thanks for the clarification anyway.
Created attachment 348972 [details] [review] box: Initialize size arrays to 0 We skip the later gtk_widget_get_preferred_foobar calls if the widget is invisible, so we don't initialize some of the array entries. Luckily, 0 is both the width and height of an invisible widget.
Review of attachment 348972 [details] [review]: sure
Attachment 348972 [details] pushed as f3f71ef - box: Initialize size arrays to 0