GNOME Bugzilla – Bug 784844
[Wayland] Firefox crash at xkb_content_ref()
Last modified: 2017-08-02 12:08:59 UTC
Firefox/Wayland crashes because the ctx is null here.
+ Trace 237641
I can't reproduce it reliably - it usually happens when FF tab is inactive and/or I switch Firefox window by Alt+Tab.
hm, Is it possible that xkb_context_new(0) call at _gdk_wayland_keymap_update_from_fd() returns null which means the context is null? Looks like so in gdb.
the only situation where xkb_context_new will return NULL is if calloc fails, ie oom.
Could be a memory corruption nullifying the pointer, would be interesting to check with valgrind.
I put assert(context) right after xkb_context_new() call and there's what I get - seems to be a failure inside xkb_context_new(): xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb firefox: gdkkeys-wayland.c:615: _gdk_wayland_keymap_update_from_fd: Assertion `context' failed. xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb firefox: gdkkeys-wayland.c:615: _gdk_wayland_keymap_update_from_fd: Assertion `context' failed. xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb firefox: gdkkeys-wayland.c:615: _gdk_wayland_keymap_update_from_fd: Assertion `context' failed.
> xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb Here's your answer. Do you have an XKB dataset (from xkeyboard-config) installed in /usr/share/X11/xkb? You should have, at a minimum, rules/evdev, keycodes/evdev, and symbols/us (amongst many other) files in that directory.
Seems so: ll /usr/share/X11/xkb: drwxr-xr-x. 2 root root 4096 Jun 16 09:23 compat drwxr-xr-x. 4 root root 4096 Jun 16 09:23 geometry drwxr-xr-x. 4 root root 4096 Jun 16 09:23 keycodes drwxr-xr-x. 2 root root 4096 Jun 16 09:23 rules drwxr-xr-x. 14 root root 4096 Jun 16 09:42 symbols drwxr-xr-x. 2 root root 4096 Jun 16 09:23 types [komat@localhost ~]$ ll /usr/share/X11/xkb/rules total 656 -rw-r--r-- 1 root root 47946 Jun 1 00:53 base -rw-r--r-- 1 root root 40533 Jun 1 00:53 base.extras.xml -rw-r--r-- 1 root root 40712 Jun 1 00:53 base.lst -rw-r--r-- 1 root root 198442 Jun 1 00:53 base.xml -rw-r--r-- 1 root root 42974 Jun 1 00:53 evdev -rw-r--r-- 1 root root 40533 Jun 1 00:53 evdev.extras.xml -rw-r--r-- 1 root root 40712 Jun 1 00:53 evdev.lst -rw-r--r-- 1 root root 198442 Jun 1 00:53 evdev.xml -rw-r--r-- 1 root root 91 May 31 17:39 README -rw-r--r-- 1 root root 743 May 31 17:39 xfree98 -rw-r--r-- 1 root root 1126 May 31 17:39 xkb.dtd lrwxrwxrwx 1 root root 4 Jun 1 00:53 xorg -> base lrwxrwxrwx 1 root root 8 Jun 1 00:53 xorg.lst -> base.lst lrwxrwxrwx 1 root root 8 Jun 1 00:53 xorg.xml -> base.xml [komat@localhost ~]$ ll /usr/share/X11/xkb/keycodes/ total 100 -rw-r--r-- 1 root root 2176 May 31 17:39 aliases -rw-r--r-- 1 root root 3401 May 31 17:39 amiga -rw-r--r-- 1 root root 1839 May 31 17:39 ataritt drwxr-xr-x. 2 root root 4096 Jun 16 09:23 digital_vndr -rw-r--r-- 1 root root 68 May 31 17:39 empty -rw-r--r-- 1 root root 8764 Jun 1 00:53 evdev -rw-r--r-- 1 root root 3715 May 31 17:39 fujitsu -rw-r--r-- 1 root root 4971 May 31 17:39 hp -rw-r--r-- 1 root root 3146 May 31 17:39 ibm -rw-r--r-- 1 root root 283 May 31 17:39 jolla -rw-r--r-- 1 root root 4466 May 31 17:39 macintosh -rw-r--r-- 1 root root 762 May 31 17:39 olpc -rw-r--r-- 1 root root 416 May 31 17:39 README drwxr-xr-x. 2 root root 4096 Jun 16 09:23 sgi_vndr -rw-r--r-- 1 root root 2954 May 31 17:39 sony -rw-r--r-- 1 root root 5076 May 31 17:39 sun -rw-r--r-- 1 root root 8634 May 31 17:39 xfree86 -rw-r--r-- 1 root root 3204 May 31 17:39 xfree98 The bug happens after some time, not right after start. The xkb_context_new() fails at Firefox child process and crashes randomly after some time.
That looks quite complete to me. The only way it can fail to add the path, is if the path does not exist, is not a directory, or the current user does not have +rx access. I know Chromium has pretty extensive sandboxing: does Firefox maybe put the child into a sandbox such that it can't access that directory after a while?
Yes, it really looks like the path is not accessible for the child process for some reason. I see the failure for the child process only while main process calls xkb_context_new() successfully.
Yes, is the permission denied error when opening /usr/share/X11/xkb. I also have log full of this - may it be related? Process 2363 (ibus-ui-gtk3) of user 500 dumped core. tack trace of thread 2363: 0 0x00007faef604a154 XkbUseExtension (libX11.so.6) 1 0x00007faef6040b96 _XkbLoadDpy (libX11.so.6) 2 0x00007faef6041468 XKeysymToKeycode (libX11.so.6) 3 0x000055864798e248 keybinding_manager_bind (ibus-ui-gtk3) 4 0x0000558647990dae panel_keybinding_manager_bind (ibus-ui-gtk3) 5 0x0000558647991b2a panel_bind_switch_shortcut (ibus-ui-gtk3) 6 0x00005586479950dd panel_construct (ibus-ui-gtk3) 7 0x000055864797d770 _application_bus_name_acquired_cb_gd_bus_signal_callback (ibus-ui-gtk3) 8 0x00007faef5429a64 emit_signal_instance_in_idle_cb (libgio-2.0.so.0) 9 0x00007faef4e54c27 g_idle_dispatch (libglib-2.0.so.0) 10 0x00007faef4e58247 g_main_dispatch (libglib-2.0.so.0) 11 0x00007faef4e585e8 g_main_context_iterate (libglib-2.0.so.0) 12 0x00007faef4e58902 g_main_loop_run (libglib-2.0.so.0) 13 0x00007faef7170a62 gtk_main (libgtk-3.so.0) 14 0x000055864797e08a application_main (ibus-ui-gtk3) 15 0x000055864797d3c0 main (ibus-ui-gtk3) 16 0x00007faef3d8d4da __libc_start_main (libc.so.6) 17 0x000055864797d3fa _start (ibus-ui-gtk3) tack trace of thread 2372:
XkbUseExtension doesn't try that: I believe that's just a matter of ibus-ui-gtk3 assuming that the display is X11, when it's in fact Wayland. Thus when we try to call into libX11, we crash.
Caused by Firefox sandbox, thanks for the hint. https://bugzilla.mozilla.org/show_bug.cgi?id=1386279