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.

+ Trace 237939

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.




+
Trace
    237952






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





+
Trace
    238674






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 ***