Seeing various apps crashing with BadMatch X11 error.
Didn't have this issue before December. Adding --no-argb is a workaround.
Output of awesome --version:
awesome devel (Human after all)
• Compiled against Lua 5.3.4 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: 0.9.2
How to reproduce the issue:
Actual result:
X protocol error: BadMatch (invalid parameter attributes) on protocol request 2
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted
Backtrace:
/usr/bin/emacs[0x51403b]
...
(firefox:24109): Gdk-ERROR **: 08:42:20.634: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 11668 error_code 8 request_code 2 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ExceptionHandler::GenerateDump cloned child 24484
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
[1] 24109 trace trap (core dumped) firefox
Expected result:
No crashes.
This is just with GTK, right? Can you do as Firefox says and run with GDK_SYNCHRONIZE=1 under gdb and get a backtrace? Alternatively, do you have x11trace / xtrace and can run under that?
I'll try and do that a little later for Firefox, but here's a backtrace from emacs since I saved that when it crashed:
Backtrace:
/usr/bin/emacs[0x51403b]
/usr/bin/emacs[0x4f9ee7]
/usr/bin/emacs[0x5140e5]
/usr/bin/emacs[0x4c73ff]
/usr/bin/emacs[0x4cb22e]
/usr/bin/emacs[0x4cb2bb]
/usr/lib64/libX11.so.6(_XError+0x11a)[0x7f1b077fa23a]
/usr/lib64/libX11.so.6(+0x45187)[0x7f1b077f7187]
/usr/lib64/libX11.so.6(+0x4522d)[0x7f1b077f722d]
/usr/lib64/libX11.so.6(_XEventsQueued+0x55)[0x7f1b077f7b65]
/usr/lib64/libX11.so.6(XPending+0x57)[0x7f1b077e97d7]
/usr/lib64/libgdk-3.so.0(+0x6bfbd)[0x7f1b07ffbfbd]
/usr/lib64/libglib-2.0.so.0(g_main_context_prepare+0x1c9)[0x7f1b07b62499]
/usr/lib64/libglib-2.0.so.0(+0x50e7b)[0x7f1b07b62e7b]
/usr/lib64/libglib-2.0.so.0(g_main_context_pending+0x27)[0x7f1b07b63017]
/usr/lib64/libgtk-3.so.0(gtk_events_pending+0xd)[0x7f1b082d4e0d]
/usr/bin/emacs[0x4c7e07]
/usr/bin/emacs[0x501181]
/usr/bin/emacs[0x501785]
/usr/bin/emacs[0x5017b9]
/usr/bin/emacs[0x501f6e]
/usr/bin/emacs[0x4d15d4]
/usr/bin/emacs[0x4d47f1]
/usr/bin/emacs[0x4292c8]
/usr/bin/emacs[0x571ea8]
/usr/bin/emacs[0x570e38]
/usr/bin/emacs[0x5ac240]
/usr/bin/emacs[0x5735a3]
/usr/bin/emacs[0x570dbb]
/usr/bin/emacs[0x5ac240]
/usr/bin/emacs[0x5735a3]
/usr/bin/emacs[0x570dbb]
/usr/bin/emacs[0x572b3b]
/usr/bin/emacs[0x571dc7]
/usr/bin/emacs[0x570e38]
/usr/bin/emacs[0x5ac240]
/usr/bin/emacs[0x5735a3]
/usr/bin/emacs[0x570dbb]
/usr/bin/emacs[0x5ac240]
/usr/bin/emacs[0x5735a3]
/usr/bin/emacs[0x570dbb]
...
[1] 23978 abort (core dumped) emacs
Also, just to add to this, using a different window manager does not exhibit the problems.
It may be related to GTK, but strangely Google Chrome still worked.
i there a chance you're using Nvidia proprietary driver?
I can reproduce the problem on 3 different systems, one has Intel graphics, one has a Radeon card, and one has an NVIDIA card with the proprietary driver.
and what is the common point between all those 3 machines? or they also have different versions of gtk and so on
I'm experiencing the same thing on NetBSD (8.99.30). Just updated pkgsrc to the latest and started seeing crashes.
If I run the same applications under twm instead of awesome they don't crash.
At least for me I can reproduce the issue by getting a tool-tip window and then moving the cursor away so the tool-tip disappears. When the tool-tip vanishes the application crashes.
The following is the output of a crash of evince (document viewer) by itself, and inside gdb with synchronous events, including the backtrace.
zmcgrew@nothingman:~ $ evince
(evince:891): GVFS-RemoteVolumeMonitor-WARNING **: 11:54:01.050: cannot open directory /usr/pkg/share/gvfs/remote-volume-monitors: Error opening directory “/usr/pkg/share/gvfs/remote-volume-monitors”: No such file or directory
(evince:891): Gdk-ERROR **: 11:54:03.498: The program 'evince' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 1387 error_code 8 request_code 2 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/BPT trap (core dumped)
zmcgrew@nothingman:~ $ GDK_SYNCHRONIZE=1 gdb --args evince
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from evince...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/pkg/bin/evince
[New LWP 1 of process 976]
(evince:976): GVFS-RemoteVolumeMonitor-WARNING **: 11:54:25.948: cannot open directory /usr/pkg/share/gvfs/remote-volume-monitors: Error opening directory “/usr/pkg/share/gvfs/remote-volume-monitors”: No such file or directory
[New LWP 7 of process 976]
^C[New LWP 6 of process 976]
[New LWP 5 of process 976]
[New LWP 4 of process 976]
[New LWP 3 of process 976]
[New LWP 2 of process 976]
Thread 3 received signal SIGINT, Interrupt.
[Switching to LWP 7 of process 976]
0x00007ac4d86a9d0a in ___lwp_park60 () from /usr/lib/libc.so.12
(gdb) b gdk_x_error
Breakpoint 1 at 0x7ac4e1e5db8f
(gdb) c
Continuing.
[Switching to LWP 1 of process 976]
Thread 2 hit Breakpoint 1, 0x00007ac4e1e5db8f in gdk_x_error () from /usr/pkg/lib/libgdk-3.so.0
(gdb) bt
(gdb)
and what is the common point between all those 3 machines? or they also have different versions of gtk and so on
They are all openSUSE. One Leap 15 and two Tumbleweed. All running Awesome 4.2. GTK versions: 3.22.30 and 3.24.2.
I can reproduce on Tumbleweed, but not Leap at the moment, so I've struck those mentions.
Don't have symbols installed, but my Firefox backtrace has some similarities to @zmcgrew 's.
(firefox:14246): Gdk-ERROR **: 12:50:51.554: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 5244 error_code 8 request_code 2 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Thread 1 "firefox" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff57f0bf5 in ?? () from /usr/lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff57f0bf5 in () at /usr/lib64/libglib-2.0.so.0
#1 0x00007ffff57f35dc in g_log_writer_default () at /usr/lib64/libglib-2.0.so.0
#2 0x00007ffff57f1857 in g_log_structured_array () at /usr/lib64/libglib-2.0.so.0
#3 0x00007ffff57f228e in g_log_structured_standard () at /usr/lib64/libglib-2.0.so.0
#4 0x00007ffff648cbfb in () at /usr/lib64/libgdk-3.so.0
#5 0x00007ffff6499953 in () at /usr/lib64/libgdk-3.so.0
#6 0x00007ffff632d23a in _XError () at /usr/lib64/libX11.so.6
#7 0x00007ffff632a187 in () at /usr/lib64/libX11.so.6
#8 0x00007ffff632a22d in () at /usr/lib64/libX11.so.6
#9 0x00007ffff632b160 in _XReply () at /usr/lib64/libX11.so.6
#10 0x00007ffff6326aad in XSync () at /usr/lib64/libX11.so.6
#11 0x00007ffff6326b4b in () at /usr/lib64/libX11.so.6
#12 0x00007ffff631c8ae in XSetWindowBackgroundPixmap () at /usr/lib64/libX11.so.6
#13 0x00007ffff64a6498 in () at /usr/lib64/libgdk-3.so.0
#14 0x00007ffff64a641d in () at /usr/lib64/libgdk-3.so.0
#15 0x00007ffff64a650f in () at /usr/lib64/libgdk-3.so.0
#16 0x00007ffff6479126 in gdk_window_withdraw () at /usr/lib64/libgdk-3.so.0
#17 0x00007ffff68c0aad in () at /usr/lib64/libgtk-3.so.0
#18 0x00007ffff58ccb6d in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#19 0x00007ffff58dfe56 in () at /usr/lib64/libgobject-2.0.so.0
#20 0x00007ffff58e8d4a in g_signal_emit_valist () at /usr/lib64/libgobject-2.0.so.0
#21 0x00007ffff58e933f in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#22 0x00007ffff68abb4c in gtk_widget_unmap () at /usr/lib64/libgtk-3.so.0
#23 0x00007ffff68c294c in () at /usr/lib64/libgtk-3.so.0
#24 0x00007ffff58ccb6d in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#25 0x00007ffff58dfe56 in () at /usr/lib64/libgobject-2.0.so.0
#26 0x00007ffff58e8d4a in g_signal_emit_valist () at /usr/lib64/libgobject-2.0.so.0
#27 0x00007ffff58e933f in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#28 0x00007ffff68b3d95 in gtk_widget_hide () at /usr/lib64/libgtk-3.so.0
#29 0x00007fffef5be033 in () at /usr/lib64/firefox/libxul.so
#30 0x00007fffef58348b in () at /usr/lib64/firefox/libxul.so
#31 0x00007fffef586333 in () at /usr/lib64/firefox/libxul.so
#32 0x00007fffef5876ae in () at /usr/lib64/firefox/libxul.so
#33 0x00007fffef71e604 in () at /usr/lib64/firefox/libxul.so
#34 0x00007fffef72166f in () at /usr/lib64/firefox/libxul.so
#35 0x00007fffef7214cf in () at /usr/lib64/firefox/libxul.so
#36 0x00007fffef7220dc in () at /usr/lib64/firefox/libxul.so
#37 0x00007fffef720d26 in () at /usr/lib64/firefox/libxul.so
#38 0x00007fffed47ad42 in () at /usr/lib64/firefox/libxul.so
#39 0x00007fffed47ce36 in () at /usr/lib64/firefox/libxul.so
#40 0x00007fffed8d04ae in () at /usr/lib64/firefox/libxul.so
#41 0x00007fffed8a12ab in () at /usr/lib64/firefox/libxul.so
#42 0x00007fffef5ab9c6 in () at /usr/lib64/firefox/libxul.so
#43 0x00007ffff06455f9 in () at /usr/lib64/firefox/libxul.so
#44 0x00007ffff06f0c52 in () at /usr/lib64/firefox/libxul.so
#45 0x00007ffff06f1517 in () at /usr/lib64/firefox/libxul.so
#46 0x00007ffff06f1b60 in () at /usr/lib64/firefox/libxul.so
#47 0x000055555555ac17 in ()
#48 0x00007ffff7283feb in __libc_start_main () at /lib64/libc.so.6
#49 0x000055555555a7ba in _start ()
(gdb) quit
(Random guess) looks like something here is wrong: https://sources.debian.org/src/gtk+3.0/3.24.2-3/gdk/x11/gdkwindow-x11.c/?hl=1697#L3008-L3024 (the only other alternative in that function is in line 3052)
Can we please collect affected GTK versions?
@francais01 What happened to GTK 3.22.30? You striked that out in an edit to your reply. Is this only with GTK 3.24.2?
Yes, I checked on my Leap machine with GTK 3.22.30 and could not reproduce, so I was probably wrong about that part. I was just looking at the package installation history on my 2 Tumbleweed machines and I cannot be conclusive as to which previous 3.24 version had the problem, but I can rule out 3.22. I'm on 3.24.2 now and just reproduced it for the backtrace above. I'm not sure if 3.24.1 had the problem.
@psychon Looking at git blame, I see this commit that looks like it appeared in 3.24.2:
https://gitlab.gnome.org/GNOME/gtk/commit/4c8fcd6a6f2adf9686296f8447895c0e2910075c
and since that release there's this:
https://gitlab.gnome.org/GNOME/gtk/commit/6a47e9a8b901b05b7a3ffb6e3929e339bbe7abc0
I too had GTK 3.24.2. Just rolled back to GTK 3.24.1 and the crashes are gone. So are my tool-tips, but I can live with that.
hm, i think i had couple of monthsweeks ago the same issue on arch with firefox and maintainer of gtk3 package had to revert that commit and next release untagged version of gtk3 with the fix:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gtk3&id=84689964b652e004fe38356ef49dc0cae6bc1754
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gtk3&id=b1cb5c8bb71ed23ba59a64dd38cfec50834e5534
i recommend closing this
Seems pretty clear this is an upstream issue. I may open an openSUSE bug. Closing this.
thanks for reporting anyway!
For reference, someone already reported it to openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1120456
FWIW: Applying https://gitlab.gnome.org/GNOME/gtk/commit/e3a1593a0984cc0156ec1892a46af8f256a64878 fixes the issue for me. Thanks for helping to troubleshoot this.
Most helpful comment
FWIW: Applying https://gitlab.gnome.org/GNOME/gtk/commit/e3a1593a0984cc0156ec1892a46af8f256a64878 fixes the issue for me. Thanks for helping to troubleshoot this.