[vim/vim] "Got X error" when I move the mouse over the icon when gvim is minimized (#1392)

125 views
Skip to first unread message

fefe17

unread,
Jan 17, 2017, 6:19:11 PM1/17/17
to vim/vim, Subscribed

gvim is very hard to use for me at the moment, because after I minimize the window, I cannot un-minimize it again. I'm using fvwm on x86_64-linux with gtk+ 3.22.7.

I have had this issue as long as I am using gvim with gtk+ 3. I need gtk+ 3 now because I have a hidpi display and gtk+ 3 has better hidpi support.

When I minimize the window, just with other apps, the windows goes away and a nice gvim icon appears on my desktop. When I move the mouse over the icon, or even use alt-tab to make it active so I can un-minimize gvim again, gvim immediately crashes with:

BadMatch (invalid parameter attributes)
Vim: Got X error
Vim: Finished.

I have no idea how to debug this. If I understand it right, this kind of X error comes in asynchronously, so it's not even clear what caused it (unless you wrote the code, hopefully). Please help!
I just verified the problem with vim 8.0 patch 206.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

Kazunobu Kuriyama

unread,
Jan 17, 2017, 6:35:38 PM1/17/17
to vim/vim, Subscribed

Did that happen with gtk versions earlier than 3.22.7?

Kazunobu Kuriyama

unread,
Jan 17, 2017, 7:36:59 PM1/17/17
to vim/vim, Subscribed

FWIW, I've just installed fvwm2 to look into the issue and find that gvim linked against 3.22.6 works fine for me regardless of its state being normal, minimized or iconified.

So, I suspect the issue could be a bug of the latest gtk3, as we haven't changed any code relevant to gtk3 for two months or so...

Michal Grochmal

unread,
Jan 17, 2017, 8:46:36 PM1/17/17
to vim/vim, Subscribed

Also, a good way to debug this would be to continuously run dbus-monitor --session and then look for messages around the time of the crash. GTK logs all applications starting and finishing into the session DBUS. You should get NameAcquired event on starting GVim and a NameLost when it dies.

Kazunobu Kuriyama

unread,
Jan 17, 2017, 9:22:00 PM1/17/17
to vim/vim, Subscribed

@grochmal

Thanks. It looks a good idea. That way we could make it possible to get a clue to the cause of the issue without asking non-developers to tweak the source code and run the debugger with the resulting executable. I think it's worth a try.

fefe17

unread,
Jan 18, 2017, 11:31:04 AM1/18/17
to vim/vim, Subscribed

I remember having this bug for a while now, and I kept upgrading my gtk+ and vim because I figured the gtk+ port is new and the kinks will go away on their own. The previous version of gtk+ I had was 3.22.1, and I definitely had the problem there, too. And I think I upgraded to 3.22.1 to see if that would fix the gvim issue, which it didn't.

Here's the output of dbus-monitor:

signal sender=org.freedesktop.DBus -> dest=:1.12 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.12"
method call sender=:1.12 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "eavesdrop=true"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.13"
string ""
string ":1.13"
method call sender=:1.13 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.14"
string ""
string ":1.14"
method call sender=:1.14 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.14 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method call sender=:1.14 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
string "org.gtk.vfs.Daemon"
uint32 0
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.14"
string ":1.14"
string ""
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.15"
string ""
string ":1.15"
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',interface='ca.desrt.dconf.Writer',path='/ca/desrt/dconf/Writer/user',arg0path='/org/gnome/desktop/interface/'"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string "org.a11y.Bus"
string ""
string ":1.15"
method call sender=:1.13 -> dest=org.a11y.Bus serial=2 path=/org/a11y/bus; interface=org.a11y.Bus; member=GetAddress
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
string "org.a11y.Bus"
uint32 1
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',interface='ca.desrt.dconf.Writer',path='/ca/desrt/dconf/Writer/user',arg0path='/org/gnome/desktop/a11y/applications/'"
method return sender=:1.15 -> dest=:1.13 reply_serial=2
string "unix:abstract=/tmp/dbus-Ntef06Wg9F,guid=f4d93ffb33a7befdffbc889a587f9723"
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.gnome.SessionManager',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/gnome/SessionManager',arg0='org.gnome.SessionManager'"
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.gnome.SessionManager',interface='org.gnome.SessionManager',path='/org/gnome/SessionManager'"
method call sender=:1.15 -> dest=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.SessionManager'"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.16"
string ""
string ":1.16"
method call sender=:1.16 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.16 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.gnome.SessionManager',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/gnome/SessionManager',arg0='org.gnome.SessionManager'"
method call sender=:1.16 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.gnome.SessionManager',interface='org.gnome.SessionManager',path='/org/gnome/SessionManager'"
method call sender=:1.16 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.SessionManager'"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.13"
string ":1.13"
string ""
^C

I don't see any NameLost messages. I pressed ^C after gvim had crashed. Could my problem be a dbus issue?

Kazunobu Kuriyama

unread,
Jan 18, 2017, 6:18:19 PM1/18/17
to vim/vim, Subscribed

@fefe17

When you move the mouse over the gvim icon, it is the window manager that is supposed to respond to the movement, not gvim.

Note that this complies with an established convention we should observe, not that gvim happens to do arbitrarily.

In other words, when you move the mouse over the icon, what happens is an interaction between you and the window manager, and there's no chance for gvim to get involved there because gvim is unmapped and hence no event is delivered to gvim.

Accordingly , I think the issue is invalid and should be closed.

Your thoughts?

fefe17

unread,
Jan 18, 2017, 6:25:44 PM1/18/17
to vim/vim, Subscribed

yet it is gvim that gets the X error, not fvwm. So it must have been something that gvim did.
Also note that other X apps have no problem with being minimized. In fact, I have never witnessed this anywhere but with gvim.

I'm guessing that gvim is setting something up in the window manager hints that collides with the rest of my setup here. I'm not sure what it could be though.

How would you debug this if it happened on your machine?

Kazunobu Kuriyama

unread,
Jan 18, 2017, 11:36:37 PM1/18/17
to vim/vim, Subscribed

yet it is gvim that gets the X error, not fvwm. So it must have been something that gvim did.

What if fvwm sends an event with wrong parameters to gvim?

So it must have been something that gvim did.

As I wrote previously, gvim cannot take any initiative while the mouse is moving over the icon because it is kept unmapped.

To reply to my view above, I think you needed to articulate what "something" was and how gvim did that.

Also note that other X apps have no problem with being minimized. In fact, I have never witnessed this anywhere but with gvim.

But, as I already reported here, gvim works fine with fvwm for me. So your argument itself doesn't make much sense.

As far as I can tell, those two facts indicate that we need to take into consideration user specific aspects of the issue such as build and run time configuration, and system and user settings,

I'm guessing that gvim is setting something up in the window manager hints that collides with the rest of my setup here. I'm not sure what it could be though.

Hmm... You wrote, "So it must have been something that gvim did," but you actually didn't have any reasoning behind that relatively strong assertion, did you?

the window manager hints that collides with the rest of my setup here.

But as you haven't referred to your setup at all so far, how could we take that into consideration? Sounds as if this issue was a user configuration issue...

So...having read your reply, I'm still not convinced that the issue is valid.

Michal Grochmal

unread,
Jan 19, 2017, 2:33:10 PM1/19/17
to vim/vim, Subscribed

I have installed gtk 3.22.7 and fvwm 2.6.7 on my Arch and I cannot replicate it.

I thought that fvwm2 was non-reparenting so you would get NameLost but it isn't. In reparenting WMs you are getting the correct NameOwerChanged. The 1.12, 1.13 in the DBUS messages are window identifiers but when the window is reparented it changes, damn.

I suspect some shared lib issue with fvwm, I'd try running both GVim and dbus-monitor from the same controlling xterm and using a log. It may provide some useful info:

dbus-monitor &
vim -gVmylog.log

And then search both the output and the log for shared lib issues (after the problem occurs, that is).

Justin Huff

unread,
Jun 1, 2017, 3:19:34 PM6/1/17
to vim/vim, Subscribed

I'm seeing what appears to be a similar issue when shading gvim. Arch, gtk 3.22.15, xfce 4.12.

When I start gvim, I get:

** (gvim:7186): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-bDU3bYGKHs: Connection refused

Full dbus log:

signal time=1496341319.254815 sender=org.freedesktop.DBus -> destination=:1.90 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.90"
signal time=1496341319.254906 sender=org.freedesktop.DBus -> destination=:1.90 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.90"
signal time=1496341319.265414 sender=:1.3 -> destination=(null destination) serial=140 path=/org/xfce/SessionManager; interface=org.xfce.Session.Manager; member=ClientRegistered
   string "/org/xfce/SessionClients/2f58c8ab5_eba0_48b5_b870_3a8cfd6a7cd0"
signal time=1496341319.265432 sender=:1.3 -> destination=(null destination) serial=141 path=/org/xfce/SessionClients/2f58c8ab5_eba0_48b5_b870_3a8cfd6a7cd0; interface=org.xfce.Session.Client; member=StateChanged
   uint32 0
   uint32 4

** (gvim:7186): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-bDU3bYGKHs: Connection refused
signal time=1496341319.411201 sender=:1.3 -> destination=(null destination) serial=142 path=/org/xfce/SessionClients/2f58c8ab5_eba0_48b5_b870_3a8cfd6a7cd0; interface=org.xfce.Session.Client; member=StateChanged
   uint32 4
   uint32 0

BadMatch (invalid parameter attributes)
Vim: Got X error
Vim: Finished.

signal time=1496341323.529611 sender=:1.3 -> destination=(null destination) serial=143 path=/org/xfce/SessionClients/2f58c8ab5_eba0_48b5_b870_3a8cfd6a7cd0; interface=org.xfce.Session.Client; member=StateChanged
   uint32 0
   uint32 7

Ernest A C

unread,
Jul 23, 2017, 11:19:25 AM7/23/17
to vim/vim, Subscribed

Same issue here with VIM 8.0 (2016 Sep 12, compiled Apr 23 2017 12:10:29) and xfwm4 version 4.12.4, on Debian. Steps to reproduce:

  1. Start gvim
  2. Roll up gvim's window

gvim displays the following messages and exits:

BadMatch (invalid parameter attributes)
Vim: Got X error
Vim: Finished.

—

fefe17

unread,
May 20, 2018, 5:15:42 AM5/20/18
to vim/vim, Subscribed

I ran gvim in xscope to get a protocol trace when the problem happens. Here are the last lines:

1.30: Client 1 --> 12 bytes
............REQUEST: XInputExtension-Request
minor opcode: 28
data: (2)
1.30: 60 bytes <-- X11 Server 1
..............REPLY: XInputExtension-Reply
data: 28
data: (13)
1.31: 32 bytes <-- X11 Server 1
..............EVENT: PropertyNotify
window: WIN 01a00007
atom: ATM 00000189
time: TIM 0017a46c
state: NewValue
1.31: Client 1 --> 24 bytes
............REQUEST: GetProperty
delete: False
window: WIN 01a00007
property: ATM 00000189
type:
long-offset: 00000000
1.31: 36 bytes <-- X11 Server 1
..............REPLY: GetProperty
format: 20
type:
bytes-after: 00000000
value: 8d 01 00 00
1.52: 32 bytes <-- X11 Server 1
..............EVENT: XKEYBOARD-Event
detail: 02
data: 40 a5 17 00 03 00
1.90: 32 bytes <-- X11 Server 1
..............EVENT: INVALID (161)
format: 20
window: WIN 01a00007
type: ATM 0000015d
data: 5e 01 00 00 ba a6
1.90: Client 1 --> 12 bytes
............REQUEST: SetInputFocus
revert-to: Parent
focus: WIN 01a00008
time: TIM 0017a6ba
1.90: 32 bytes <-- X11 Server 1
..............ERROR: Match
minor opcode: 0000
major opcode: 2a

I'm not sure if the INVALID event from the server could be caused by fvwm, or maybe it's not actually invalid but xscope just does not understand it. The SetInputFocus to Window 01a00008 looks legit though, that request appears earlier in the dump and worked then.

Any suggestions how to debug this? I have recently upgraded to xorg-server-1.20.0. Open to suggestions.

fefe17

unread,
May 20, 2018, 5:17:58 AM5/20/18
to vim/vim, Subscribed

BTW: Tried killing fvwm and running gvim in twm. Minimizing works then, however twm does not support the shaped color icon, so it could be that, too.

fefe17

unread,
May 20, 2018, 5:23:25 AM5/20/18
to vim/vim, Subscribed

Updating fvwm to the latest git snapshot did not help.

fefe17

unread,
May 20, 2018, 5:30:53 AM5/20/18
to vim/vim, Subscribed

I installed jwm for testing, and with jwm I can minimize and restore gvim.

Tony Mechelynck

unread,
May 20, 2018, 7:16:19 AM5/20/18
to vim/vim, Subscribed

I'm running gvim 8.1.5 for GTK2/Gnome2 (and earlier versions before that) but not in the same window manager: IIRC I have a KDE display manager and a Gnome window manager. My distro is openSUSE 42.3. The icon has a gray V on a green square-on-a-point, and minimizing / unminimizing / maximizing gvim doesn't give me problems; in particular it doesn't crash.

I have had small problems in the past with GTK3 but not crashes, they were more of an æsthetic nature (where tastes may legitimately vary), so I went back to GTK2 which according to its makers is "programmed for EOL in a few years but at the moment still supported".

Best regards,
Tony.

fefe17

unread,
May 20, 2018, 8:27:33 AM5/20/18
to vim/vim, Subscribed

Yes I also never had this kind of issue when I build my vim against gtk+2.
However gtk+2 is basically EOL and gtk+3 has HiDpi support for 4k monitors, and I have one of those, so I am stuck with the gtk+3 backend in vim.

Kazunobu Kuriyama

unread,
May 20, 2018, 12:19:55 PM5/20/18
to vim/vim, Subscribed

Since atoms (except for the predefined ones) and resource IDs are assigned by the X server at runtime, thus varying between X11 sessions, the xscope log above is of no use to anyone other than you who should be able to know the names of atoms using xlsatoms(1) and the relationship between resource IDs and X clients using xwininfo(1) at that particular X session.

Note that, other than those entries named atom, type, format are also atoms. Without knowing their names or other things, no one knows what to do with the log.

Still, from the last few lines of the log, I guess the protocol error happened when you tried to de-iconify gvim. It's the window manager who is responsible for changing the parent window from the root window to the most outer window where you have some ornaments such as the title bar, the close button etc. there. That window is managed only by the window manager. Apparently, gvim has nothing to do with the protocol error.

Kazunobu Kuriyama

unread,
May 20, 2018, 3:51:41 PM5/20/18
to vim/vim, Subscribed

............REQUEST: SetInputFocus
revert-to: Parent
focus: WIN 01a00008
time: TIM 0017a6ba
1.90: 32 bytes <-- X11 Server 1
..............ERROR: Match
minor opcode: 0000
major opcode: 2a

In C, the protocol request SetInputFocus is issued by invoking XSetInputFocus(3). According to the manual page, the error BadMatch results if the window to be focused is not viewable at the time the function is called.

GTK+ 3 GVim doesn't call the function directly. Having looked at the source code of GTK+ 3, I found there are only two different places where the function is used; one in gdk/x11/gdkwindow-x11.c and another in gdk/x11/gdkdisplay.c. Both use it the same way and are guarded against the protocol error as follows:

      /* There is no way of knowing reliably whether we are viewable;
       * so trap errors asynchronously around the XSetInputFocus call
       */
      gdk_x11_display_error_trap_push (display);
      XSetInputFocus (GDK_DISPLAY_XDISPLAY (display),
                      GDK_WINDOW_XID (window),
                      RevertToParent,
                      timestamp);
      gdk_x11_display_error_trap_pop_ignored (display);

Note the comment given there. Basically, what gdk_x11_display_error_trap_push() does is to ignore the protocol error by disabling the default error handler temporarily. (N.B. X11's default error handler terminates the program unconditionally when an error happens.)

This shows that GTK+ 3 GVim cannot abort by and for itself even if it actually gets that particular protocol error. If it still aborts, the possibility only lies in the outermost window that is attached to GVim by the window manager.

Reply all
Reply to author
Forward
0 new messages