Under a guest VM running Gnome 3.26.2 Wayland, epiphany core dumps when Mesa 17.3.x is installed including the latest, 17.3.3. Reverting back to 17.2.8 and the problem goes away. In the system logs the following can be found: Feb 05 23:18:35 lfs15 systemd-coredump[1122]: Process 1112 (epiphany) of user 1000 dumped core. Stack trace of thread 1112: #0 0x00007fef7ba4e081 __strlen_avx2 (libc.so.6) #1 0x00007fef7b97dc5e __GI___strdup (libc.so.6) #2 0x00007fef72fea1da wayland_drm_init (libEGL.so.1) #3 0x00007fef72fde1c9 dri2_bind_wayland_display_wl (libEGL.so.1) #4 0x00007fef72fd4b38 eglBindWaylandDisplayWL (libEGL.so.1) #5 0x00007fef781379f2 _ZN6WebKit17WaylandCompositorC2Ev (libwebkit2gtk-4.0.so.37) #6 0x00007fef78137c88 _ZN6WebKit17WaylandCompositor9singletonEv (libwebkit2gtk-4.0.so.37) #7 0x00007fef78132d9a _ZN6WebKit27HardwareAccelerationManagerC2Ev (libwebkit2gtk-4.0.so.37) #8 0x00007fef78132e18 _ZN6WebKit27HardwareAccelerationManager9singletonEv (libwebkit2gtk-4.0.so.37) #9 0x00007fef7813c07d _ZN6WebKit14WebPreferences23platformInitializeStoreEv (libwebkit2gtk-4.0.so.37) #10 0x00007fef77f18cc2 _ZN6WebKit14WebPreferences6createERKN3WTF6StringES4_S4_ (libwebkit2gtk-4.0.so.37) #11 0x00007fef77f1f11e _ZN6WebKit14WebPreferences24createWithLegacyDefaultsERKN3WTF6StringES4_S4_ (libwebkit2gtk-4.0.so.37) #12 0x00007fef77eee70a _ZN6WebKit12WebPageGroupC2ERKN3WTF6StringEbb (libwebkit2gtk-4.0.so.37) #13 0x00007fef77eee931 _ZN6WebKit12WebPageGroup13createNonNullERKN3WTF6StringEbb (libwebkit2gtk-4.0.so.37) #14 0x00007fef77f28817 _ZN6WebKit14WebProcessPoolC2ERN3API24ProcessPoolConfigurationE (libwebkit2gtk-4.0.so.37) #15 0x00007fef77f29127 _ZN6WebKit14WebProcessPool6createERN3API24ProcessPoolConfigurationE (libwebkit2gtk-4.0.so.37) #16 0x00007fef780f8146 _ZL27webkitWebContextConstructedP8_GObject (libwebkit2gtk-4.0.so.37) #17 0x00007fef7d1d4e10 g_object_new_internal (libgobject-2.0.so.0) #18 0x00007fef7d1d69a0 g_object_new_valist (libgobject-2.0.so.0) #19 0x00007fef7d1d6cfc g_object_new (libgobject-2.0.so.0) #20 0x00007fef780f3ae2 webkit_web_context_new_with_website_data_manager (libwebkit2gtk-4.0.so.37) #21 0x00007fef7d6ac48a ephy_embed_shell_create_web_context (libephymain.so) #22 0x00007fef7d6ad833 ephy_embed_shell_startup (libephymain.so) #23 0x00007fef7d693146 ephy_shell_startup (libephymain.so) #24 0x00007fef7d1cf9ad g_closure_invoke (libgobject-2.0.so.0) #25 0x00007fef7d1e1f0e signal_emit_unlocked_R (libgobject-2.0.so.0) #26 0x00007fef7d1ea4d5 g_signal_emit_valist (libgobject-2.0.so.0) #27 0x00007fef7d1eae92 g_signal_emit (libgobject-2.0.so.0) #28 0x00007fef7cbb88a2 g_application_register (libgio-2.0.so.0) #29 0x00007fef7cbb903f g_application_real_local_command_line (libgio-2.0.so.0) #30 0x00007fef7cbb93b6 g_application_run (libgio-2.0.so.0) #31 0x0000000000402ba8 main (epiphany) #32 0x00007fef7b918f2a __libc_start_main (libc.so.6) #33 0x0000000000402e9a _start (epiphany) Stack trace of thread 1114: #0 0x00007fef7b9e311b __GI___poll (libc.so.6) #1 0x00007fef7cef85d1 g_main_context_poll (libglib-2.0.so.0) #2 0x00007fef7cef86dc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fef5de0a8cd dconf_gdbus_worker_thread (libdconfsettings.so) #4 0x00007fef7cf1eb75 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fef755d84d8 start_thread (libpthread.so.0) #6 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1115: #0 0x00007fef7b9e311b __GI___poll (libc.so.6) #1 0x00007fef7cef85d1 g_main_context_poll (libglib-2.0.so.0) #2 0x00007fef7cef86dc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fef7cef8721 glib_worker_main (libglib-2.0.so.0) #4 0x00007fef7cf1eb75 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fef755d84d8 start_thread (libpthread.so.0) #6 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1118: #0 0x00007fef755de77d futex_wait_cancelable (libpthread.so.0) #1 0x00007fef0f5ddb53 thread_function (swrast_dri.so) #2 0x00007fef0f5dda07 impl_thrd_routine (swrast_dri.so) #3 0x00007fef755d84d8 start_thread (libpthread.so.0) #4 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1120: #0 0x00007fef755de77d futex_wait_cancelable (libpthread.so.0) #1 0x00007fef0f5ddb53 thread_function (swrast_dri.so) #2 0x00007fef0f5dda07 impl_thrd_routine (swrast_dri.so) #3 0x00007fef755d84d8 start_thread (libpthread.so.0) #4 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1117: #0 0x00007fef755de77d futex_wait_cancelable (libpthread.so.0) #1 0x00007fef0f5ddb53 thread_function (swrast_dri.so) #2 0x00007fef0f5dda07 impl_thrd_routine (swrast_dri.so) #3 0x00007fef755d84d8 start_thread (libpthread.so.0) #4 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1119: #0 0x00007fef755de77d futex_wait_cancelable (libpthread.so.0) #1 0x00007fef0f5ddb53 thread_function (swrast_dri.so) #2 0x00007fef0f5dda07 impl_thrd_routine (swrast_dri.so) #3 0x00007fef755d84d8 start_thread (libpthread.so.0) #4 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1113: #0 0x00007fef755deb36 futex_abstimed_wait_cancelable (libpthread.so.0) #1 0x00007fef77667aa1 _ZN7bmalloc9Scavenger13threadRunLoopEv (libjavascriptcoregtk-4.0.so.18) #2 0x00007fef67b2086f execute_native_thread_routine (libstdc++.so.6) #3 0x00007fef755d84d8 start_thread (libpthread.so.0) #4 0x00007fef7b9ed5df __clone (libc.so.6) Stack trace of thread 1116: #0 0x00007fef7b9e311b __GI___poll (libc.so.6) #1 0x00007fef7cef85d1 g_main_context_poll (libglib-2.0.so.0) #2 0x00007fef7cef8962 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fef7cbe3d76 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007fef7cf1eb75 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fef755d84d8 start_thread (libpthread.so.0) #6 0x00007fef7b9ed5df __clone (libc.so.6) I've done a git bisect: 12181b501732b0c098b90e4128dc44032d08df00 is the first bad commit. More info: GL_RENDERER: llvmpipe (LLVM 5.0, 256 bits) kms_swrast_dri.so
Emil, I'm assuming this commit causes swrast platform_wayland to start exposing EGL_WL_bind_wayland_display, which assumes there's a DRM device?
Created attachment 137171 [details] [review] Force-disable extension/error out if using API while extension is not set (In reply to Daniel Stone from comment #1) > Emil, I'm assuming this commit causes swrast platform_wayland to start > exposing EGL_WL_bind_wayland_display, which assumes there's a DRM device? That shouldn't be it - dri2_set_WL_bind_wayland_display() [attempts to] set the extension only if we have device_name. With latter being NULL based on the crash. Skimming through webkit [might be outdated?] it seems to be doing the most common and silly mistakes - uses the function pointers w/o checking for the extension string. https://github.com/WebKit/webkit/blob/68fc1e2ab9c374f41cf290aa749b460539cf2756/Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp#L374 To be on the safe side: Wayne can you please confirm if the extension is advertised before/after the patch? Does any of the two hunks of the attached patch help?
Yeah, good catch! Bug filed: https://bugs.webkit.org/show_bug.cgi?id=182490
Hi Emil, I don't know what you mean by 'if the extension is advertised before/after the patch'. How do I check if an extension is advertised? The first hunk didn't work. i.e. still got a core dump. The second hunk and both hunks together fixed the issue.
es2_info does not return EGL_WL_bind_wayland_display either before or after the patch, if that is what you were asking for?
(In reply to Wayne Blaszczyk from comment #5) > es2_info does not return EGL_WL_bind_wayland_display either before or after > the patch, if that is what you were asking for? for egl information you'll want eglinfo, es2_info outputs gles2 information ;)
(In reply to Eric Engestrom from comment #6) > (In reply to Wayne Blaszczyk from comment #5) > > es2_info does not return EGL_WL_bind_wayland_display either before or after > > the patch, if that is what you were asking for? > > for egl information you'll want eglinfo, es2_info outputs gles2 information > ;) I don't have eglinfo. What package does that come from? es2_info did come back with EGL_WL_bind_wayland_display on my host box which has an Intel HD chip.
(In reply to Wayne Blaszczyk from comment #7) > I don't have eglinfo. What package does that come from? it's in mesa-demos, but it's not necessarily provided by a package in your distro (I think ubuntu doesn't have it, for instance, while arch does). eglinfo itself is at https://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglinfo.c I think this doesn't really matter anymore though, as Emil has found the issue and Daniel has filed a bug with Webkit :)
(In reply to Eric Engestrom from comment #8) > (In reply to Wayne Blaszczyk from comment #7) > > I don't have eglinfo. What package does that come from? > > it's in mesa-demos, but it's not necessarily provided by a package in your > distro (I think ubuntu doesn't have it, for instance, while arch does). > eglinfo itself is at > https://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglinfo.c > > I think this doesn't really matter anymore though, as Emil has found the > issue and Daniel has filed a bug with Webkit :) The reason why eglinfo was not installed on my system was that 'make install' for mesa-demos does not install it. I've now rebuilt mesa-demos and manually copied over the binary (As per Arch build instructions). Running eglinfo before and after the patch does not change. EGL_EXT_platform_wayland existed before and after. Does that change the situation in any way?
(In reply to Daniel Stone from comment #3) > Yeah, good catch! Bug filed: https://bugs.webkit.org/show_bug.cgi?id=182490 I've applied the following patch to webkitgtk-2.18.6 https://bug-182490-attachments.webkit.org/attachment.cgi?id=333283 Epiphany now starts fine with Mesa 17.3.3. But there is a difference in the warnings. Epiphany under Mesa 17.3.3 produces the following: WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer. Nested Wayland compositor could not initialize EGL Epiphany under Mesa 17.2.8 produces the following: WaylandCompositor requires eglCreateImage and eglDestroyImage. Nested Wayland compositor could not initialize EGL So, I guess it does get further in its initializeEGL method. Thanks.
The WebKit patch has now landed upstream. Not supporting bind_wayland_display for swrast is to be expected, since for unaccelerated paths we use the wl_shm support built into the server. For future, I suspect the best way to support the WebKit compositor on swrast, is for the WebKit compositor to make sure it supports wl_shm on the server side (and uploading the contents to textures, etc), and also making BindWaylandDisplay just return TRUE without doing anything on swrast.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.