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 787422 - Crashes trying to set keyboard map when logging into Wayland session
Crashes trying to set keyboard map when logging into Wayland session
Status: RESOLVED DUPLICATE of bug 782688
Product: mutter
Classification: Core
Component: wayland
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-09-07 20:43 UTC by Debarshi Ray
Modified: 2018-08-08 06:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
clutter/evdev: Handle NULL keymap (1.10 KB, patch)
2017-09-07 22:08 UTC, Florian Müllner
none Details | Review
backend-native: Handle keymap lookup failure (977 bytes, patch)
2017-09-07 22:09 UTC, Florian Müllner
none Details | Review

Description Debarshi Ray 2017-09-07 20:43:52 UTC
Fedora 26 and Wayland here. gnome-shell kept crashing while trying to log in. A few failed attempts, reboots and dnf update later it managed to get in.

I have:
gnome-shell-3.24.3-1.fc26.x86_64
mutter-3.24.4-1.fc26.x86_64
gjs-1.48.6-2.fc26.x86_64
libxkbcommon-0.7.1-3.fc26.x86_64

I have a British keyboard so my default layout is English (UK). I also have the Bengali (probhat (m17n)) input source configured, if that matters.

Looks like clutter_evdev_set_keyboard_map is being called with a NULL keymap.

Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.

Thread 10 (Thread 0x7f9329b91700 (LWP 1742))

  • #0 syscall
  • #1 g_cond_wait_until
  • #2 g_async_queue_pop_intern_unlocked
  • #3 g_thread_pool_thread_proxy
  • #4 g_thread_proxy
  • #5 start_thread
  • #6 clone

Thread 8 (Thread 0x7f932a392700 (LWP 1741))

  • #0 syscall
  • #1 g_cond_wait_until
  • #2 g_async_queue_pop_intern_unlocked
  • #3 g_thread_pool_thread_proxy
  • #4 g_thread_proxy
  • #5 start_thread
  • #6 clone

Thread 5 (Thread 0x7f932ab93700 (LWP 1739))

  • #0 syscall
  • #1 g_cond_wait_until
  • #2 g_async_queue_pop_intern_unlocked
  • #3 g_async_queue_timeout_pop
  • #4 g_thread_pool_thread_proxy
  • #5 g_thread_proxy
  • #6 start_thread
  • #7 clone

Thread 1 (Thread 0x7f939f047ac0 (LWP 1482))

  • #0 xkb_keymap_ref
    at src/keymap.c line 59
  • #1 clutter_evdev_set_keyboard_map
    at evdev/clutter-device-manager-evdev.c line 2546
  • #2 meta_backend_native_set_keymap
    at backends/native/meta-backend-native.c line 486
  • #3 ffi_call_unix64
  • #4 ffi_call
  • #5 gjs_invoke_c_function(JSContext*, Function*, JS::HandleObject, JS::HandleValueArray const&, mozilla::Maybe<JS::MutableHandle<JS::Value> >&, GIArgument*)
    at gi/function.cpp line 1021
  • #6 function_call(JSContext*, unsigned int, JS::Value*)
    at gi/function.cpp line 1340
  • #7 0x00007f939ef8af85 in
  • #8 0x00007fff556eec10 in
  • #9 0x00007fff556eeba8 in
  • #10 0x00007fff556ef7a0 in
  • #11 ()

Comment 1 Debarshi Ray 2017-09-07 20:56:34 UTC
(In reply to Debarshi Ray from comment #0)
> Looks like clutter_evdev_set_keyboard_map is being called with a NULL keymap.

And that's because xkb_keymap_new_from_names is returning a NULL keymap. The backtrace shows values of the local variables.
Comment 2 Florian Müllner 2017-09-07 22:08:54 UTC
Created attachment 359379 [details] [review]
clutter/evdev: Handle NULL keymap

Callers may (intentionally or unintentionally) pass in a NULL keymap,
handle this case gracefully instead of crashing.
Comment 3 Florian Müllner 2017-09-07 22:09:02 UTC
Created attachment 359380 [details] [review]
backend-native: Handle keymap lookup failure

xkb_keymap_new_from_names() may return NULL - handle this case by
leaving the keymap unset instead of crashing.
Comment 4 Florian Müllner 2017-09-07 22:13:29 UTC
Only compile-tested, but should take care of the crash. Although I have honestly no idea what happens with no keymap set ...
Comment 5 Debarshi Ray 2017-09-07 22:28:59 UTC
I have no clue why xkb_keymap_new_from_names is returning NULL. I have applied them locally against my system's copy of mutter. Let's see what happens.
Comment 6 Jonas Ådahl 2017-09-08 02:06:01 UTC
There will be error messages in the journal from libxkbcommon with where it failed. The other bugs that are the same as this has had seemingly valid input, and I have not yet grasped why libxkbcomon fails to load the keymap.

We should probably handle this returning NULL, but add a g_warning() when it happens, and probably leave the layout to what it was before, so that at least keyboard input works at all. I suspect get_keymap() returning NULL will cause issues elsewhere.
Comment 7 Debarshi Ray 2017-09-12 20:12:45 UTC
libxkbcommon failed again with a NULL keymap and led to a slightly different crash:

Program terminated with signal SIGSEGV, Segmentation fault.

Thread 14 (Thread 0x7fe25bbc6700 (LWP 1708))

  • #0 syscall
  • #1 g_cond_wait_until
  • #2 g_async_queue_pop_intern_unlocked
  • #3 g_thread_pool_thread_proxy
  • #4 g_thread_proxy
  • #5 start_thread
  • #6 clone

Thread 1 (Thread 0x7fe2cb4bdac0 (LWP 1487))

  • #0 xkb_keymap_ref
    at src/keymap.c line 59
  • #1 xkb_state_new
    at src/state.c line 589
  • #2 clutter_evdev_update_xkb_state
    at evdev/clutter-device-manager-evdev.c line 2438
  • #3 meta_backend_native_set_keymap
    at backends/native/meta-backend-native.c line 486
  • #4 ffi_call_unix64
  • #5 ffi_call
  • #6 gjs_invoke_c_function(JSContext*, Function*, JS::HandleObject, JS::HandleValueArray const&, mozilla::Maybe<JS::MutableHandle<JS::Value> >&, GIArgument*)
    at gi/function.cpp line 1021
  • #7 function_call(JSContext*, unsigned int, JS::Value*)
    at gi/function.cpp line 1340
  • #8 0x00007fe2cb400f85 in
  • #9 0x00007ffc07382390 in
  • #10 0x00007ffc07382328 in
  • #11 0x00007ffc07382f20 in
  • #12 ()

Comment 8 Debarshi Ray 2017-09-12 20:15:20 UTC
My journal says:

org.gnome.Shell.desktop[1487]: xkbcommon: ERROR: Couldn't find file "rules/evdev" in include paths
org.gnome.Shell.desktop[1487]: xkbcommon: ERROR: 1 include paths searched:
org.gnome.Shell.desktop[1487]: xkbcommon: ERROR:         /usr/share/X11/xkb
org.gnome.Shell.desktop[1487]: xkbcommon: ERROR: 1 include paths could not be added:
org.gnome.Shell.desktop[1487]: xkbcommon: ERROR:         /home/rishi/.xkb
org.gnome.Shell.desktop[1487]: xkbcommon: ERROR: Couldn't look up rules 'evdev', model 'pc105+inet', layout 'gb,us', variant ',', options ''
Comment 9 Debarshi Ray 2017-10-11 09:17:23 UTC
Also happens on Fedora 27 with:
gnome-shell-3.26.1-1.fc27.x86_64
mutter-3.26.1-2.fc27.x86_64
gjs-1.50.1-1.fc27.x86_64
libxkbcommon-0.7.1-5.fc27.x86_64

This is a different laptop with the default layout being English (US). I also have the Bengali (probhat (m17n)) input source and a Czech layout configured.

Same backtrace, but slightly different journal entries due to having different layouts:
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR: Couldn't find file "rules/evdev" in include paths
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR: 1 include paths searched:
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR:         /usr/share/X11/xkb
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR: 1 include paths could not be added:
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR:         /home/rishi/.xkb
org.gnome.Shell.desktop[1682]: xkbcommon: ERROR: Couldn't look up rules 'evdev', model 'pc105+inet', layout 'us,cz,us', variant ',,', options ''
Comment 10 Christian Stadelmann 2017-11-02 22:53:51 UTC
(In reply to Debarshi Ray from comment #0)
> Fedora 26 and Wayland here. gnome-shell kept crashing while trying to log
> in. A few failed attempts, reboots and dnf update later it managed to get in.
> 

The same backtrace is also a crasher on GNOME 3.24 and 3.22. Redhat Bugzilla has more details:
https://bugzilla.redhat.com/show_bug.cgi?id=1398142
https://bugzilla.redhat.com/show_bug.cgi?id=1398128
https://bugzilla.redhat.com/show_bug.cgi?id=1441490
https://bugzilla.redhat.com/show_bug.cgi?id=1507656 (only the last one is on GNOME 3.26).

And one of these has a reference to https://bugzilla.gnome.org/show_bug.cgi?id=782688 , which seems to be a duplicate.
Comment 11 Debarshi Ray 2018-08-08 06:04:05 UTC
Also happens on Fedora 28 with:
gnome-shell-3.28.3-1.fc28.x86_64
mutter-3.28.3-3.fc28.x86_64
gjs-1.52.3-1.fc28.x86_64
libxkbcommon-0.8.0-5.fc28.x86_64

(gdb) thread apply all bt

Thread 16 (Thread 0x7f13b886f700 (LWP 1680))

  • #0 syscall
  • #1 g_cond_wait_until
    at gthread-posix.c line 1449
  • #2 g_async_queue_pop_intern_unlocked
    at gasyncqueue.c line 422
  • #3 g_async_queue_timeout_pop_unlocked
    at gasyncqueue.c line 570
  • #4 g_thread_pool_wait_for_new_task
    at gthreadpool.c line 262
  • #5 g_thread_pool_thread_proxy
    at gthreadpool.c line 296
  • #6 g_thread_proxy
    at gthread.c line 784
  • #7 start_thread
  • #8 clone

Thread 15 (Thread 0x7f138530e700 (LWP 2035))

  • #0 syscall
  • #1 g_cond_wait_until
    at gthread-posix.c line 1449
  • #2 g_async_queue_pop_intern_unlocked
    at gasyncqueue.c line 422
  • #3 g_async_queue_timeout_pop_unlocked
    at gasyncqueue.c line 570
  • #4 g_thread_pool_wait_for_new_task
    at gthreadpool.c line 262
  • #5 g_thread_pool_thread_proxy
    at gthreadpool.c line 296
  • #6 g_thread_proxy
    at gthread.c line 784
  • #7 start_thread
  • #8 clone

Thread 12 (Thread 0x7f1395822700 (LWP 1979))

  • #0 syscall
  • #1 g_cond_wait_until
    at gthread-posix.c line 1449
  • #2 g_async_queue_pop_intern_unlocked
    at gasyncqueue.c line 422
  • #3 g_async_queue_timeout_pop
    at gasyncqueue.c line 543
  • #4 g_thread_pool_wait_for_new_pool
    at gthreadpool.c line 167
  • #5 g_thread_pool_thread_proxy
    at gthreadpool.c line 364
  • #6 g_thread_proxy
    at gthread.c line 784
  • #7 start_thread
  • #8 clone

Thread 1 (Thread 0x7f13dd890240 (LWP 1668))

  • #0 xkb_keymap_unref
    at src/keymap.c line 66
  • #1 clutter_evdev_set_keyboard_map
    at evdev/clutter-device-manager-evdev.c line 2397
  • #2 meta_backend_native_set_keymap
    at backends/native/meta-backend-native.c line 431
  • #3 ffi_call_unix64
  • #4 ffi_call
  • #5 gjs_invoke_c_function(JSContext*, Function*, JS::HandleObject, JS::HandleValueArray const&, mozilla::Maybe<JS::MutableHandle<JS::Value> >, GIArgument*)
    at gi/function.cpp line 1088
  • #6 function_call(JSContext*, unsigned int, JS::Value*)
    at /usr/include/c++/8/new line 169
  • #7 0x000038dc81768810 in
  • #8 0x00007fff141fdaa8 in
  • #9 0x00007fff141fda40 in
  • #10 ()

Comment 12 Debarshi Ray 2018-08-08 06:07:22 UTC

*** This bug has been marked as a duplicate of bug 782688 ***