Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Abou Al Montacir]

Package: libgtk-3-0  
Version: 3.22.3-2


After last update this was gone, so this can probably be closed now.
-- 
Cheers,
Abou Al Montacir

signature.asc
Description: This is a digitally signed message part

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Abou Al Montacir]

Control: severity -1 grave

On Mon, 31 Oct 2016 19:49:11 + Stephan Dollberg 
wrote:
> On Wed, 26 Oct 2016 09:26:39 -0400 (EDT) Olivier Fourdan <
> ofour...@redhat.com> wrote:
> >
> > Hi Andreas
> >
> > > I bisected this issue which pointed at it being introduced in:
> > >
> > > commit 12579fe71b3b8f79eb9c1b80e429443bcc437dd0
> > > Author: Olivier Fourdan 
> > > Date:   Thu Oct 6 16:49:39 2016 +0200
> > > [...]
> > > Oliver do you have any ideas or hints on how we should proceed to
> identify
> > > the proper fix?
> >
> > Yes, this is a known issue:
> >
> >   https://bugzilla.gnome.org/show_bug.cgi?id=773387
> >
> > But right now, I don't know how to revert this change and fix both bugs
> 771320 and 767713 differently...
...
> 
> there seem to be patches in Arch for the gvim breakage. Could those help
> debian as well?
...

I've updated my laptop today and hit this bug. I do believe that this bug should
be tagged RC from the beginning thus avoiding the buggy package to hit testing.

I'm setting the severity to grave because the new GTK3 gvim, which is the
default alternative is not usable at all. Until a workaround is provided I think
this is the right severity.

Note for users hitting this bug:
# aptitude install vim-gtk
...
# update-alternatives --config gvim
There are 2 choices for the alternative gvim (providing /usr/bin/gvim).

  SelectionPath   Priority   Status

* 0/usr/bin/vim.gtk3   50auto mode
  1/usr/bin/vim.gtk50manual mode
  2/usr/bin/vim.gtk3   50manual mode

Press  to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/bin/vim.gtk to provide /usr/bin/gvim (gvim) in
manual mode

This will allow you to continue enjoying the ViM experience.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Stephan Dollberg]

On Wed, 26 Oct 2016 09:26:39 -0400 (EDT) Olivier Fourdan <
ofour...@redhat.com> wrote:
>
> Hi Andreas
>
> > I bisected this issue which pointed at it being introduced in:
> >
> > commit 12579fe71b3b8f79eb9c1b80e429443bcc437dd0
> > Author: Olivier Fourdan 
> > Date:   Thu Oct 6 16:49:39 2016 +0200
> > [...]
> > Oliver do you have any ideas or hints on how we should proceed to
identify
> > the proper fix?
>
> Yes, this is a known issue:
>
>   https://bugzilla.gnome.org/show_bug.cgi?id=773387
>
> But right now, I don't know how to revert this change and fix both bugs
771320 and 767713 differently...
>
> Cheers,
> Olivier
>
>

Hello,

there seem to be patches in Arch for the gvim breakage. Could those help
debian as well?

https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-Fix-widget-sizing-on-current-Gtk-3.22-branch.patch?h=packages/vim
https://git.archlinux.org/svntogit/packages.git/tree/trunk/0002-Further-fix-widget-sizing.patch?h=packages/vim

Cheers,
Stephan

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Olivier Fourdan]

Hi Andreas

> I bisected this issue which pointed at it being introduced in:
> 
> commit 12579fe71b3b8f79eb9c1b80e429443bcc437dd0
> Author: Olivier Fourdan 
> Date:   Thu Oct 6 16:49:39 2016 +0200
> [...]
> Oliver do you have any ideas or hints on how we should proceed to identify
> the proper fix?

Yes, this is a known issue:

  https://bugzilla.gnome.org/show_bug.cgi?id=773387

But right now, I don't know how to revert this change and fix both bugs 771320 
and 767713 differently...

Cheers,
Olivier

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Andreas Henriksson]

Hello Ben Armstrong.

On Tue, Oct 25, 2016 at 02:20:27PM -0300, Ben Armstrong wrote:
> Package: libgtk-3-0
> Version: 3.22.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I upgraded from libgtk-3-0 3.22.1-1 to 3.22.2-1.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I attempted to open gvim (vim.gtk3 -g), with or without a filename as 
> parameter.
> 
>* What was the outcome of this action?
> 
> Whenever I opened gvim, I saw these messages:
> 
> (gvim:1904): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width 
> >= -1' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> Then a window was opened, but no buffer contents were shown, and
> nothing could be typed in the buffer area, making it impossible to use
> the editor. The buttons and menus at the top were still functional,
> however.
> 
> I downgraded back to libgtk-3-0 3.22.1-1, and that was effective to
> resolve the issue.  The above error messages went away, the buffer was
> shown, and the editor functioned properly.
> 
>* What outcome did you expect instead?
> 
> I expected no error messages, and I expected the buffer contents to
> be empty and ready to accept input (no filename specified) or else
> contain the contents of the specified file.
> 
> I supposed that since there was only a minor revision bump for this
> release, it was more likely libgtk-3-0 broke than gvim itself.
> Re-assign as needed if I guessed incorrectly.

I bisected this issue which pointed at it being introduced in:

commit 12579fe71b3b8f79eb9c1b80e429443bcc437dd0
Author: Olivier Fourdan 
Date:   Thu Oct 6 16:49:39 2016 +0200

gdkwindow: configure native windows in move_native_children()

ClutterEmbed on Wayland uses a subsurface and relocates it on configure
events, but when placed within a scrolled window, no configure event is
emitted and the ClutterEmbed subsurface remains static.

Emit a configure event for native windows in GdkWindow's internal
move_native_children() so that custom widgets relying on configure
events such as ClutterEmbed can relocate their stuff.

Similarly, when switching to/from normal/maximized/fullscreen states
which change the shadows' size and possibly shows/hides a header bar,
we need to emit a configure event even if the abs_x/abs_y haven't
changed to make sure the subsurface is size appropriately.

https://bugzilla.gnome.org/show_bug.cgi?id=771320
https://bugzilla.gnome.org/show_bug.cgi?id=767713

Oliver do you have any ideas or hints on how we should proceed to identify
the proper fix?

Regards,
Andreas Henriksson

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Simon McVittie]

On Tue, 25 Oct 2016 at 15:39:46 -0300, Ben Armstrong wrote:
> #5  0x557569f9 in gui_position_components (total_width=1) at 
> gui.c:1355
> #6  0x5575982c in gui_resize_shell (pixel_width=, 
> pixel_height=pixel_height@entry=1) at gui.c:1470

Well, that looks like bad news: you presumably wanted every widget to be
more than 1x1 pixels.

Sorry, I don't have any insights into why this would be happening or
whether it's vim or Gtk that regressed.

> And then I flipped back to the editor window and it was scuttled in the same
> way as my original bug report. Would you like any more backtraces (e.g. at the
> points where I did 'continue' above? If so, which ones, just the last, or each
> one?)

If in doubt, more information is better than less information. Hopefully
it's always the GUI thread that's interesting (as it looks as though it
was on the one you quoted), so "bt" rather than "thread apply all bt"
would be sufficient.

S

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Ben Armstrong]

Simon,

Here is the info you requested ...

On 25/10/16 03:14 PM, Simon McVittie wrote:

What 'guiopts' do you use in gvim? (type ":set guiopts?" into gvim)


Do you mean ":set guioptions?" If so:

  guioptions=aegimrLtTf


Which Gtk theme are you using? I ask because I use vim.gtk3 myself, and
I can't reproduce this with the default Adwaita theme.


I'm on Cinnamon, so whatever it uses by default. I assume Adwaita. Not 
sure the "right way" to query, but guessing:


$ gtk-query-settings  | grep -i theme
 gtk-theme-name: "Adwaita"
gtk-icon-theme-name: "gnome"
!   gtk-fallback-icon-theme: NULL
 gtk-key-theme-name: "Default"
  gtk-cursor-theme-name: "Adwaita"
  gtk-cursor-theme-size: 24
   gtk-sound-theme-name: "freedesktop"
  gtk-application-prefer-dark-theme: FALSE


It would probably be useful if you can get a backtrace from the crash,
the invalid pixman_region32_init_rect call, and/or the invalid
size request.

The size request is probably the most useful:

 $ sudo apt install gdb
 $ G_DEBUG=fatal_criticals gdb /usr/bin/vim.gtk3
 (gdb) run
 ... when it crashes with the critical warning you quoted ...
 (gdb) thread apply all bt

To make the backtrace useful, you will probably need the libgtk-3-0-dbgsym
and vim-gtk3-dbgsym packages from the debug symbols archive. Please see
 for more information about
backtraces and debug symbols.


Here you go:

Thread 5 (Thread 0x7fffea277700 (LWP 4547)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x75fd92aa in g_cond_wait_until () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75f67e89 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x75fbbcf6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x75fbb325 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x73fd5464 in start_thread (arg=0x7fffea277700) at 
pthread_create.c:333
#6  0x72e4c9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 4 (Thread 0x7fffeaa78700 (LWP 4546)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x75fd92aa in g_cond_wait_until () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75f67e89 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x75fbbcf6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x75fbb325 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x73fd5464 in start_thread (arg=0x7fffeaa78700) at 
pthread_create.c:333
#6  0x72e4c9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7fffe3fff700 (LWP 4545)):
#0  0x72e4356d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x75f939d6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75f93d62 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7657b4e6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x75fbb325 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x73fd5464 in start_thread (arg=0x7fffe3fff700) at 
pthread_create.c:333
#6  0x72e4c9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7fffeb839700 (LWP 4544)):
#0  0x72e4356d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x75f939d6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75f93aec in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x75f93b31 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x75fbb325 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x73fd5464 in start_thread (arg=0x7fffeb839700) at 
pthread_create.c:333
#6  0x72e4c9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x77f26a40 (LWP 4540)):
#0  0x75f99241 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x75f9a64d in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75f9a7af in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x55769914 in gtk_form_move_resize (form=0x55d33260, widget=0x55f8b0f0, 
x=0, y=0, w=, h=)
at gui_gtk_f.c:1166
#4  0x5575eebc in gui_mch_set_text_area_pos (x=, y=, 
w=, h=)
at gui_gtk.c:827
#5  0x557569f9 in gui_position_components (total_width=1) at gui.c:1355
#6  0x5575982c in gui_resize_shell (pixel_width=, 
pixel_height=pixel_height@entry=1) at gui.c:1470
#7  0x5576144f in form_configure_event (widget=widget@entry=0x55d33260, 
event=0x55fae3e0, data=)
at gui_gtk_x11.c:4440
#8  0x776fb55c in _gtk_marshal_BOOLEAN__BOXED (closure=0x56126920, 
return_value=0x7fffcf60, n_param_values=,
param_values=0x7fffcfc0, invocation_hint=, 
marshal_data=) at 

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[D. B.]

With respect (and forasmuch as I love anything that promotes vim) - if some
program and/or theme has managed to request <= 0 size for a widget, then
it's broken GTK+, not the other way around.

That said, on a quick glance at the gtk-3-22 branch, I can't see any
changes in gtkwidget.c that would've broken this, but of course extra debug
info may reveal that some other widget is leading to this.

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Simon McVittie]

On Tue, 25 Oct 2016 at 14:20:27 -0300, Ben Armstrong wrote:
> I upgraded from libgtk-3-0 3.22.1-1 to 3.22.2-1.
...
> I attempted to open gvim (vim.gtk3 -g), with or without a filename as 
> parameter.
...
> (gvim:1904): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width 
> >= -1' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug

What 'guiopts' do you use in gvim? (type ":set guiopts?" into gvim)

Which Gtk theme are you using? I ask because I use vim.gtk3 myself, and
I can't reproduce this with the default Adwaita theme.

It would probably be useful if you can get a backtrace from the crash,
the invalid pixman_region32_init_rect call, and/or the invalid
size request.

The size request is probably the most useful:

$ sudo apt install gdb
$ G_DEBUG=fatal_criticals gdb /usr/bin/vim.gtk3
(gdb) run
... when it crashes with the critical warning you quoted ...
(gdb) thread apply all bt

To make the backtrace useful, you will probably need the libgtk-3-0-dbgsym
and vim-gtk3-dbgsym packages from the debug symbols archive. Please see
 for more information about
backtraces and debug symbols.

Thanks,
S

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Ben Armstrong]

Package: libgtk-3-0
Version: 3.22.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I upgraded from libgtk-3-0 3.22.1-1 to 3.22.2-1.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I attempted to open gvim (vim.gtk3 -g), with or without a filename as parameter.

   * What was the outcome of this action?

Whenever I opened gvim, I saw these messages:

(gvim:1904): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= 
-1' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

Then a window was opened, but no buffer contents were shown, and
nothing could be typed in the buffer area, making it impossible to use
the editor. The buttons and menus at the top were still functional,
however.

I downgraded back to libgtk-3-0 3.22.1-1, and that was effective to
resolve the issue.  The above error messages went away, the buffer was
shown, and the editor functioned properly.

   * What outcome did you expect instead?

I expected no error messages, and I expected the buffer contents to
be empty and ready to accept input (no filename specified) or else
contain the contents of the specified file.

I supposed that since there was only a minor revision bump for this
release, it was more likely libgtk-3-0 broke than gvim itself.
Re-assign as needed if I guessed incorrectly.

Thanks,
Ben

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.22.0-1
ii  hicolor-icon-theme  0.15-1
ii  libatk-bridge2.0-0  2.22.0-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-5
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.3-2
ii  libcups22.2.1-1
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.1-1
ii  libgtk-3-common 3.22.2-1
ii  libjson-glib-1.0-0  1.2.2-1
ii  libpango-1.0-0  1.40.3-2
ii  libpangocairo-1.0-0 1.40.3-2
ii  libpangoft2-1.0-0   1.40.3-2
ii  librest-0.7-0   0.8.0-2
ii  libsoup2.4-12.56.0-1
ii  libwayland-client0  1.11.0-2
ii  libwayland-cursor0  1.11.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  12.0.3-3
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.2-1
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.6.1-1
ii  libxml2 2.9.4+dfsg1-2
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.7-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.22.1-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.30.1.1-1
ii  librsvg2-common  2.40.16-1

-- no debconf information