After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769566 - GtkScrollbar warning "How does the code know the size to allocate?"
GtkScrollbar warning "How does the code know the size to allocate?"
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 770228 770540 791014 793679 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-08-05 22:26 UTC by Gerald Nunn
Modified: 2018-05-02 17:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Minimal test case (1.64 KB, text/plain)
2018-02-08 21:14 UTC, Egmont Koblinger
  Details
VTE workaround (3.95 KB, patch)
2018-02-10 21:48 UTC, Egmont Koblinger
committed Details | Review

Description Gerald Nunn 2016-08-05 22:26:04 UTC
GTK3 on Arch was upgraded yesterday to 3.20.8, ever since then my application Terminix has been issuing the following warning to the console whenever I resize the window:

(terminix:6853): Gtk-WARNING **: Allocating size to GtkScrollbar 0x15c65c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

I noticed that bug https://bugzilla.gnome.org/show_bug.cgi?id=765700 seems somewhat similar and I've tried commenting out the style and provider I add to the scrollbar to see if it made a difference but no change.
Comment 1 Timm Bäder 2016-08-07 07:43:15 UTC
That is very hard to say, can you run your application in gdb with G_DEBUG=fatal-warnings and gtk+ debugging symbols and print a backtrace when that warning appears?
Comment 2 Gerald Nunn 2016-08-08 16:36:24 UTC
As requested:

[Thread 0x7fffdb3fe700 (LWP 23358) exited]

(terminix:23348): Gtk-WARNING **: Allocating size to GtkScrollbar 0x14d45c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

Thread 1 "terminix" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff225570b in g_logv () from /usr/lib/libglib-2.0.so.0
(gdb) bt
  • #0 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #1 g_log
    from /usr/lib/libglib-2.0.so.0
  • #2 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 5997
  • #3 gtk_box_size_allocate_no_center
    at gtkbox.c line 811
  • #4 gtk_box_allocate_contents
    at gtkbox.c line 1205
  • #5 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #6 gtk_box_size_allocate
    at gtkbox.c line 1219
  • #7 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #8 gtk_box_size_allocate_no_center
    at gtkbox.c line 811
  • #9 gtk_box_allocate_contents
    at gtkbox.c line 1205
  • #10 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #11 gtk_box_size_allocate
    at gtkbox.c line 1219
  • #12 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #13 gtk_box_size_allocate_no_center
    at gtkbox.c line 811
  • #14 gtk_box_allocate_contents
    at gtkbox.c line 1205
  • #15 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #16 gtk_box_size_allocate
    at gtkbox.c line 1219
  • #17 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #18 gtk_event_box_size_allocate
    at gtkeventbox.c line 597
  • #19 gtk_widget_size_allocate_with_baseline
  • #20 gtk_box_size_allocate_no_center
    at gtkbox.c line 811
  • #21 gtk_box_allocate_contents
    at gtkbox.c line 1205
  • #22 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #23 gtk_box_size_allocate
    at gtkbox.c line 1219
  • #24 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #25 gtk_box_size_allocate_no_center
    at gtkbox.c line 811
  • #26 gtk_box_allocate_contents
    at gtkbox.c line 1205
  • #27 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #28 gtk_box_size_allocate
    at gtkbox.c line 1219
  • #29 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #30 gtk_widget_size_allocate
    at gtkwidget.c line 6217
  • #31 gtk_stack_allocate
    at gtkstack.c line 2294
  • #32 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #33 gtk_stack_size_allocate
    at gtkstack.c line 2230
  • #34 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #35 gtk_notebook_allocate_stack
    at gtknotebook.c line 2456
  • #36 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #37 gtk_box_gadget_allocate_child
  • #38 gtk_box_gadget_allocate
    at gtkboxgadget.c line 474
  • #39 gtk_css_gadget_allocate
    at gtkcssgadget.c line 782
  • #40 gtk_notebook_size_allocate
    at gtknotebook.c line 2473
  • #41 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6136
  • #42 gtk_widget_size_allocate
    at gtkwidget.c line 6217
  • #43 gtk_bin_size_allocate
    at gtkbin.c line 312
  • #44 gtk_overlay_size_allocate
    at gtkoverlay.c line 330
  • #45 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #46 ??
    from /usr/lib/libgobject-2.0.so.0
  • #47 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #48 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #49 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6134
  • #50 gtk_widget_size_allocate
    at gtkwidget.c line 6217
  • #51 gtk_window_size_allocate
    at gtkwindow.c line 7647
  • #52 gtk_application_window_real_size_allocate
    at gtkapplicationwindow.c line 660
  • #53 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #54 ??
    from /usr/lib/libgobject-2.0.so.0
  • #55 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #56 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #57 gtk_widget_size_allocate_with_baseline
    at gtkwidget.c line 6134
  • #58 gtk_widget_size_allocate
    at gtkwidget.c line 6217
  • #59 gtk_window_move_resize
    at gtkwindow.c line 9741
  • #60 gtk_window_check_resize
    at gtkwindow.c line 8275
  • #61 ??
    from /usr/lib/libgobject-2.0.so.0
  • #62 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #63 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #64 gtk_container_idle_sizer
    at gtkcontainer.c line 2064
  • #65 ??
    from /usr/lib/libgobject-2.0.so.0
  • #66 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #67 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #68 _gdk_frame_clock_emit_layout
    at gdkframeclock.c line 634
  • #69 gdk_frame_clock_paint_idle
    at gdkframeclockidle.c line 408
  • #70 gdk_threads_dispatch
    at gdk.c line 720
  • #71 ??
    from /usr/lib/libglib-2.0.so.0
  • #72 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #73 ??
    from /usr/lib/libglib-2.0.so.0
  • #74 g_main_context_iteration
    from /usr/lib/libglib-2.0.so.0
  • #75 g_application_run
    from /usr/lib/libgio-2.0.so.0
  • #76 gio.Application.Application.run(immutable(char)[][])
    at ../../.dub/packages/gtk-d-3.3.1/src/gio/Application.d line 889
  • #77 D main
    at source/app.d line 95

Comment 3 Igor 2016-08-25 15:35:24 UTC
I started getting a similar message with xfce4-terminal after upgrading to gtk+ 3.20.8.
Comment 4 Christian Persch 2016-09-03 21:59:01 UTC
*** Bug 770228 has been marked as a duplicate of this bug. ***
Comment 5 Christian Persch 2016-09-03 21:59:26 UTC
*** Bug 770540 has been marked as a duplicate of this bug. ***
Comment 6 Igor 2016-10-12 10:50:21 UTC
Not seeing this anymore after Arch Linux has upgraded to gtk+ 3.22.1.
Comment 7 Igor 2017-02-15 11:03:59 UTC
Started seeing this again after upgrading to 3.22.8. Regression?
Comment 8 Alberto Garcia 2017-03-29 22:38:37 UTC
This might be related to bug 773814
Comment 9 Egmont Koblinger 2018-02-08 15:00:30 UTC
I've made some investigation in bug 791014, and at this point I really need help from a GTK+ guru who can tell whether VTE is doing it wrong, or it's a GtkScrollbar bug. Copy-pasting here the most relevant bits:

When the window height changes, GTK+ calls size_allocate for both VTE and the Scrollbar "in parallel". VTE handling this event also causes synchronous changes to the Adjustment (and in turn to the Scrollbar). That is, the Scrollbar receives changes both from the bottom (GTK+) and sideways (VTE) at the "same time". It looks to me that this is what Scrollbar doesn't like.

We'd need input from a GTK+ expert whether this is really a sufficient reason for Scrollbar to warn and is really something we should avoid, or whether not being able to handle this is a bug in Scrollbar.

A solution/workaround from VTE could be to defer these gtk_adjustment_set_whatever() calls to when idle.

xfce4-terminal allows you to place the scrollbar on the left. The warning doesn't appear in that case. Debugging both VTE and GTK+ reveals that indeed size_allocate is called on the left widget first, then on the right. Apparently in the "scrollbar on the left" case it has already settled with the new allocation when VTE pokes it, so it's okay.
Comment 10 Egmont Koblinger 2018-02-08 21:14:16 UTC
Created attachment 368165 [details]
Minimal test case

This tiny test app reproduces the warning exactly as in VTE-based apps.

It consists of two widgets next to each other: a "fake vte" (a GtkLabel subclassed so that on size_allocate it modifies the adjustment), and a scrollbar reflecting the adjustment.

Just as with the scrollbar on the left with xfce4-terminal, swapping the packing order makes the warning go away.

I strongly suspect it's a GTK+ bug. I believe it should be a legal operation to alter the adjustment from a size_allocate, and that's what any VTE-like widget (with an external scrollbar, rather than being inside a GtkScrolledWindow) would also reasonably do. And, apart from this warning, it works correctly. (Note that there are plenty of other, non-VTE-related occurrences of this same warning posted across the web.)
Comment 11 Egmont Koblinger 2018-02-08 21:19:41 UTC
*** Bug 791014 has been marked as a duplicate of this bug. ***
Comment 12 Egmont Koblinger 2018-02-08 21:24:36 UTC
Benjamin (adding you to CC),

You seem to be the guy who knows the story of this warning. Could you please look at this bug? I firmly suspect that in one particular case it's erroneously emitted by GTK+, as detailed in the previous comments.

Thanks!
Comment 13 Benjamin Otte (Company) 2018-02-08 23:38:58 UTC
Ah yes, the adjustment issue.

What happens in your example is this:

1. GtkBox::size-allocate is called. It queries sizes for its children and computes their allocations.
2. The box calls FakeVte::size-allocate. It updates the adjustment.
3. gtk_range_adjustment_value_changed() is triggered. It updates its presentation and while doing so calls gtk_widget_queue_resize().
4. The box calls GtkScrollbar::size-allocate. The warning happens.

Since the scrollbar queued a resize in #3 but the allocation was computed with the size request from #1, the warning is correct.

I have no idea how a fix should look, but as long as the scrollbar/range code queues a resize during size allocation, that warning is correct.
Comment 14 Egmont Koblinger 2018-02-09 13:52:08 UTC
I'm totally not familiar with GTK+ internals, so apologies in advance if my questions are silly.

> 3. gtk_range_adjustment_value_changed() is triggered. It updates its
> presentation and while doing so calls gtk_widget_queue_resize().

Why would a gtk_range_adjustment_{,value_}changed trigger a queue_resize()? I think it should only queue_draw. A change to the range parameters should only change how the GtkScrollbar renders its own contents (where it draws the handlebar), but nothing about its overall size/allocation. Or what am I missing?

It's like as if VTE kept calling queue_resize on itself during its normal operation, like scrolling due to newly appeared output... no, this is its own private business, it repaints the contents without tampering with the allocation.
Comment 15 Egmont Koblinger 2018-02-09 21:47:50 UTC
gtk_range_adjustment_{,value_}changed() call gtk_range_calc_slider() [and this latter method is solely called from these two].

gtk_range_calc_slider() calls gtk_css_gadget_queue_resize(priv->slider_gadget), and this is what in turn calls gtk_widget_queue_resize(range).

I'm totally not familiar with the concept of gadgets, feels something like a "lightweight widget" to me. gtk_css_gadget_queue_resize() simply calls gtk_widget_queue_resize() on the gadget's owner widget.

That looks like the problem here, because it's obviously needed to resize the slider gadget, but we'd need to avoid resizing the range widget.

I'm on 3-22. 3.91.2's news says "All gadgets have been replaced by widgets", so I guess chances are the situation is completely different on gtk4 ??
Comment 16 Benjamin Otte (Company) 2018-02-09 22:08:02 UTC
Yes, GTK4 is completely different.

Apparently, this resize was added because of bug 765410. Not that that bug explains much about why it's there.
Comment 17 Egmont Koblinger 2018-02-09 22:46:29 UTC
Reverting that indeed eliminates this warning in this test app and VTE-based apps.

When Matthias Clasen says "We haven't fully tracked down yet why a queue_allocation is not sufficient here, it should", Timm Bäder says "I don't know how to handle that case" and you say "I have no idea how a fix should look", I think it's time for me to give up :-D I probably won't be able to contribute anything more to this bug.

I'm hoping it is (or will be) gone with gtk4. (I guess you wouldn't want to just entirely remove this warning from gtk3, right?)

Until then, we'll just live with this warning, or I might work it around in VTE by changing the adjustment from idle.
Comment 18 Benjamin Otte (Company) 2018-02-09 23:25:26 UTC
What might work is trying to swap the order I outlined in comment 13.

If you can make it so the adjustment gets set before the container tries measuring the children, you might get away without the warning.
Comment 19 Egmont Koblinger 2018-02-09 23:49:05 UTC
(In reply to Benjamin Otte (Company) from comment #18)

> If you can make it so the adjustment gets set before the container tries
> measuring the children, you might get away without the warning.

This would mean a subclassed GtkHBox or something similar, right? I'm not interested in any workaround that would go to gnome-terminal and leave the warning for all other VTE-based apps.

I'd either like to see it being fixed or worked around in GTK+, for which I definitely don't have enough expertise and time, or in VTE. In the latter, the order in which the widgets' size-allocates are called is out of our control, in fact, I don't think there's even a way for VTE to find the scrollbar, or even to figure out whether it's shown at all. From VTE the only workaround I can think of is to delay changing the adjustment via e.g. g_idle_add().
Comment 20 Egmont Koblinger 2018-02-10 21:48:39 UTC
Created attachment 368224 [details] [review]
VTE workaround

VTE already sets upper/lower asynchronously, so just simply move the setting of pagesize/pageincr/stepincr there as well.
Comment 21 Egmont Koblinger 2018-02-10 22:22:06 UTC
See also bug 767136, and Timm's suggestion there to guard this warning with G_ENABLE_CONSISTENCY_CHECKS.
Comment 22 Christian Persch 2018-02-21 22:39:44 UTC
*** Bug 793679 has been marked as a duplicate of this bug. ***
Comment 23 Egmont Koblinger 2018-03-04 13:39:51 UTC
Comment on attachment 368224 [details] [review]
VTE workaround

(VTE workaround was reviewed in bug 793435; submitted for 0.52.)
Comment 24 konkor 2018-03-17 12:00:46 UTC
How to stop this madness all SYSTEM JOURNAL in that JOKE WARNING!
It's like a spam.

Is there some compiler flags to fix it?
Comment 25 Timm Bäder 2018-03-17 12:13:24 UTC
> It's like a spam.

So is your comment.

> Is there some compiler flags to fix it?

No. If you compile gtk3 yourself anyway, you can as well just remove that one line for the warning, if you really care so much.
Comment 26 konkor 2018-03-17 14:18:48 UTC
This bug is like in all gtk apps with custom widgets and comportability of gtk versions less than 3.20. Is it OK?

Can you make this warn shorter? This funny question at least...

BTW I fixed my apps but I can't fix all of them.
Comment 28 konkor 2018-03-17 14:29:31 UTC
Awesome! :)
Comment 29 GNOME Infrastructure Team 2018-05-02 17:20:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME'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.gnome.org/GNOME/gtk/issues/650.