Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Vim/Gtk3 crashes with BadMatch after Alt-Tabbing to a different desktop #18

Open
jmacloue opened this issue Jan 8, 2020 · 5 comments
Open

Vim/Gtk3 crashes with BadMatch after Alt-Tabbing to a different desktop #18

jmacloue opened this issue Jan 8, 2020 · 5 comments
Assignees
@ThomasAdam
Labels
help wanted Development help required (see `difficulty:*`) type:bug Something's broken!
Projects
FVWM3

Comments

@jmacloue
Copy link

jmacloue commented Jan 8, 2020

Possibly related to fvwmorg/fvwm#59

I'm using Slackware64-current, FVWM 2.6.9 and Vim 8.2.0050 - both sufficiently recent though not the bleeding edge. FVWM configured with 4 desktops with 2x2 screens.

gVim is built with Gtk3 GUI and works as expected most of the time - until I try to Alt-Tab to another desktop and WindowList is drawn over gVim window. The xscope output is as follows:

96.50: Client 1 -->   12 bytes
	 ............REQUEST: SetInputFocus
	           revert-to: Parent
	               focus: WIN 04400008
	                time: TIM 00a9b8a0
96.51: 					  32 bytes <-- X11 Server 1
					 ..............ERROR: Match
					        minor opcode: 0000
					        major opcode: 2a
96.51: 					  32 bytes <-- X11 Server 1
					 ..............EVENT: ClientMessage
					              source: SendEvent
					              format: 20
					              window: WIN 04400007
					                type: <WM_PROTOCOLS>

As far as I understand, it happens as follows. WindowList steals the input focus and informs gVim of it by sending a PartiallyObscured NotifyEvent, and as gVim tries to get it back from it - it is no longer visible as another desktop is already shown, which is in line with X11 Proto spec .

According to gVim bug #1392, Gtk3 is already handling this scenario by guarding XSetInputFocus() invocation but somehow it is not enough for FVWM.

Alt-Tabbing over the same desktop works as expected, so I believe it is related to how FVWM implements multiple desktops. Though I don't see such problems with other Gtk3 applications - it looks quite generic so it may surface elsewhere as well, and a fix or a good workaround would certainly be nice: maybe guarding XSetInputFocus() in fvwm/focus.c same as Gtk3 does?

PS Previous gVim version built against Gtk2 does not have this problem - most likely building current gVim against Gtk2 will also "fix" - or, rather, obscure it, but eventually Gtk2 will become obsolete.
@ThomasAdam
Copy link
Member

Can you provide me with a backtrace, please? I've tried to reproduce this, but cannot.

@jmacloue
Copy link
Author

Can you provide me with a backtrace, please? I've tried to reproduce this, but cannot.

Hm-m, that's strange - I have the same issue consistently on three workstations (all Slackware64-current). Among other things it means that my configuration (almost identical) may be to blame for this, so I need to review it first.

And, of all the possible stack traces, which one would be the most useful?

To my understanding, it could be that gVim receives a BadMatch event actually intended to something /under/ its window: like, root window trying to get focus back and not expecting this to fail. Sorry if it is utter heresy, I'm not a programmer. But if I am correct - the answer may lie in stack traces issued by gVim (and all underlying Gtk3 multi-threaded orchestra), main FVWM process, or FvwmPager. Posting all three would certainly be an overkill.

@ThomasAdam
Copy link
Member

And, of all the possible stack traces, which one would be the most useful?

If it's vim which is crashing, that'll definitely help me. Any/all strack traces which are coredumping will help, especially if it's FVWM.

@jmacloue
Copy link
Author

Sorry, did too much reading on the matter to post a proper bug report. Let's start from the way to reproduce.

OS details:

  • Platform: Slackware64 14.2 and current
  • FVWM fvwm 2.6.9-2-g749ed65c compiled with: ./configure --prefix=/opt/jmcl --enable-mandoc "CFLAGS=-g -O2 -fPIC" --libdir=/opt/jmcl/lib64 --enable-debug-msgs --disable-perllib
  • Vim 8.2.0110 compiled with: ./configure --prefix=/opt/jmcl/ --enable-multibyte --with-features=huge --with-x --enable-gui=gtk3 "CFLAGS=-g -O2 -fPIC" STRIP=/bin/true
  • Gtk3 3.18.9 (also reproduces with 3.24.13) - from stock Slackware
  • Xorg 1.18.3 (also reproduces with 1.20.6) - from stock Slackware

Steps to reproduce:

  1. Start FVWM with default config: /opt/jmcl/bin/fvm -f /opt/jmcl/share/fvwm/default-config/config
  2. Switch to Desktop 2 and start an xterm
  3. Switch to Desktop 0 and invoke gVim: /opt/jmcl/bin/vim -f -g
  4. With focus in gVim window use Alt-Tab to switch to xterm at Desktop 2
  5. gVim exits with an error:

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

Details

gdb's threads apply all bt after Vim exited is not particularly interesting:

Thread 3 (Thread 0x7fffe962e700 (LWP 3738)):
#0  0x00007ffff47692fd in poll () at /lib64/libc.so.6
fvwmorg/fvwm#1  0x00007ffff5fbf964 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#2  0x00007ffff5fbfce2 in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#3  0x00007ffff65db986 in  () at /usr/lib64/libgio-2.0.so.0
fvwmorg/fvwm#4  0x00007ffff5fe5275 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#5  0x00007fffed7fc684 in start_thread () at /lib64/libpthread.so.0
fvwmorg/fvwm#6  0x00007ffff4774eed in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fffe9e2f700 (LWP 3737)):
#0  0x00007ffff47692fd in poll () at /lib64/libc.so.6
fvwmorg/fvwm#1  0x00007ffff5fbf964 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#2  0x00007ffff5fbfa6c in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#3  0x00007ffff5fbfaa9 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#4  0x00007ffff5fe5275 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#5  0x00007fffed7fc684 in start_thread () at /lib64/libpthread.so.0
fvwmorg/fvwm#6  0x00007ffff4774eed in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7ffff7f81900 (LWP 3733)):
#0  0x00007ffff46a7ff0 in exit () at /lib64/libc.so.6
fvwmorg/fvwm#1  0x0000000000518fc8 in mch_exit (r=r@entry=1) at os_unix.c:3360
fvwmorg/fvwm#2  0x0000000000612b59 in getout (exitval=exitval@entry=1) at main.c:1708
fvwmorg/fvwm#3  0x00000000004dfce1 in preserve_exit () at misc1.c:2151
fvwmorg/fvwm#4  0x00000000005160dc in x_error_handler (dpy=<optimized out>, error_event=<optimized out>) at os_unix.c:1550
fvwmorg/fvwm#5  0x00007ffff55f74b5 in _XError () at /usr/lib64/libX11.so.6
fvwmorg/fvwm#6  0x00007ffff55f4537 in  () at /usr/lib64/libX11.so.6
fvwmorg/fvwm#7  0x00007ffff55f45e5 in  () at /usr/lib64/libX11.so.6
fvwmorg/fvwm#8  0x00007ffff55f4e85 in _XEventsQueued () at /usr/lib64/libX11.so.6
fvwmorg/fvwm#9  0x00007ffff55e70e7 in XPending () at /usr/lib64/libX11.so.6
fvwmorg/fvwm#10 0x00007ffff726c7c1 in  () at /usr/lib64/libgdk-3.so.0
fvwmorg/fvwm#11 0x00007ffff5fbf3e1 in g_main_context_check ()
    at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#12 0x00007ffff5fbf908 in  () at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#13 0x00007ffff5fbfa6c in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
fvwmorg/fvwm#14 0x00000000005ed144 in gui_mch_wait_for_chars (wtime=4000)
    at gui_gtk_x11.c:6293
fvwmorg/fvwm#15 0x00000000005b7181 in ui_wait_for_chars_or_timer (wtime=4000, wait_func=
    0x5dcb40 <gui_wait_for_chars_3>, interrupted=0x7fffffffd4cc, ignore_input=0) at ui.c:487
fvwmorg/fvwm#16 0x00000000005b8f0c in inchar_loop (buf=buf@entry=0x8c50bc <typebuf_init+60> "", maxlen=maxlen@entry=68, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@entry=9, wait_func=wait_func@entry=
    0x5dcb20 <gui_wait_for_chars_or_timer>, resize_func=resize_func@entry=0x0)
    at ui.c:383
fvwmorg/fvwm#17 0x00000000005dd285 in gui_wait_for_chars_buf (buf=0x8c50bc <typebuf_init+60> "", maxlen=68, wtime=-1, tb_change_cnt=9) at gui.c:2964
fvwmorg/fvwm#18 0x00000000005b8956 in ui_inchar (buf=buf@entry=0x8c50bc <typebuf_init+60> "", maxlen=maxlen@entry=68, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@entry=9) at ui.c:225
fvwmorg/fvwm#19 0x00000000004a8bb1 in inchar (buf=0x8c50bc <typebuf_init+60> "", maxlen=204, wait_time=-1) at getchar.c:3364
fvwmorg/fvwm#20 0x00000000004a9867 in vgetorpeek (advance=advance@entry=1)
    at getchar.c:3143
fvwmorg/fvwm#21 0x00000000004aa92d in vgetc () at getchar.c:1616
fvwmorg/fvwm#22 0x00000000004aadb9 in safe_vgetc () at getchar.c:1850
fvwmorg/fvwm#23 0x00000000004f9589 in normal_cmd (oap=oap@entry=0x7fffffffd900, toplevel=toplevel@entry=1) at normal.c:569
fvwmorg/fvwm#24 0x0000000000613ada in main_loop (cmdwin=cmdwin@entry=0, noexmode=noexmode@entry=0) at main.c:1511
fvwmorg/fvwm#25 0x0000000000615142 in vim_main2 () at main.c:901
fvwmorg/fvwm#26 0x000000000041400e in main (argc=<optimized out>, argv=<optimized out>)
    at main.c:444

(just indicates Vim received an X error which triggered an unclean exit, no indication on what was the request that caused the error)

I have tried using xscope to get the X11 exchange that led to the error - here's the event dump:

xscope-vim.txt.gz

(note an exchange at the end of file - SetInputFocus to parent and subsequent BadMatch - supposedly as the target is not visible)

Must be some kind of race condition as with GDK_SYNCHRONIZE=1 the error doesn't happen, and sometimes (very rare - 5% of time) it takes more than one Alt-Tab to crash Vim. Here's xscope output taken with GDK_SYNCHRONIZE=1 in the same scenario:

xscope-sync.txt.gz

Also when the WindowList menu pops outside of gVim window - Alt-Tab doesn't crash gVim.

Using mouse binding to show WindowList works the same as Alt-Tab: almost always a crash when it paints over gVim, works without a crash if outside gVim.

To re-iterate, nothing I have seen so far indicates that the issue is isolated to Vim, looks more a general Gtk3 problem with FVWM.

PS I have used Xephyr in a window to run the tests: Xephyr -screen 1024x768 :2, with xscope in front of it: xscope -i1 -o2, and set DISPLAY to ":1".

PPS And, no, GDK_SYNCHRONIZE=1 is not a proper fix and not too good a workaround.

@ThomasAdam
Copy link
Member

Perfect. Thank you -- I'll try and get round to looking at this soon.

I'm moving this to the fvwm3 repository so I don't lose it -- any fixes I have, I will backport to fvwm2, as it's a common bug in the core.

@ThomasAdam ThomasAdam transferred this issue from fvwmorg/fvwm Jan 13, 2020
@ThomasAdam ThomasAdam added the type:bug Something's broken! label Jan 13, 2020
@ThomasAdam ThomasAdam added this to To do in FVWM3 Jan 13, 2020
@ThomasAdam ThomasAdam added this to the post-1.0 milestone May 3, 2020
@ThomasAdam ThomasAdam self-assigned this May 3, 2020
@NsCDE NsCDE mentioned this issue Dec 9, 2020
Closed
@ThomasAdam ThomasAdam removed this from the post-1.0 milestone Dec 20, 2020
@ThomasAdam ThomasAdam added the help wanted Development help required (see `difficulty:*`) label Dec 20, 2020
@NsCDE NsCDE mentioned this issue Mar 17, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ThomasAdam ThomasAdam

Labels
help wanted Development help required (see `difficulty:*`) type:bug Something's broken!
Projects
FVWM3
Status: To do
FVWM3
  
To do
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ThomasAdam @jmacloue