It seems that it's impossible to build Yelp (which links against WebKitGTK) if DISPLAY is unset: Gtk-CRITICAL **: 18:22:42.130: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed WARNING **: 18:22:42.132: Unable to connect to dbus: Cannot autolaunch D-Bus without X11 $DISPLAY Unable to init server: Could not connect: Connection refused I don't have a full backtrace with all symbols but this one already points at the problem: Thread 1 "libyelp-scan" received signal SIGABRT, Aborted. 0x00007ffff7c56761 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff7c56761 in raise () at /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7c4055b in abort () at /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff4ba02ed in () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #3 0x00007ffff507079b in WebKit::HardwareAccelerationManager::HardwareAccelerationManager() () at ../Source/WebKit/UIProcess/gtk/HardwareAccelerationManager.cpp:55 #4 0x00007ffff507081c in WTF::NeverDestroyed<WebKit::HardwareAccelerationManager>::NeverDestroyed<>() () at DerivedSources/ForwardingHeaders/wtf/NeverDestroyed.h:52 #5 WebKit::HardwareAccelerationManager::singleton() () at ../Source/WebKit/UIProcess/gtk/HardwareAccelerationManager.cpp:36 #6 0x00007ffff50786d9 in WebKit::WebPreferences::platformInitializeStore() () at ../Source/WebKit/UIProcess/gtk/WebPreferencesGtk.cpp:42 #7 0x00007ffff4eea222 in WebKit::WebPreferences::create(WTF::String const&, WTF::String const&, WTF::String const&) () at ../Source/WebKit/UIProcess/WebPreferences.cpp:45 #8 0x00007ffff4fbb101 in _WebKitSettingsPrivate::_WebKitSettingsPrivate() () at ../Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:59 #9 0x00007ffff7fa8e6d in g_type_create_instance () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x00007ffff7f886dd in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x00007ffff7f8a5e9 in g_object_new_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007ffff4fb5588 in webkit_settings_new_with_settings() () at ../Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1577 #13 0x00007ffff7e32726 in yelp_view_get_global_settings () at libyelp/yelp-view.c:153 #14 0x00007ffff7e3274d in settings_show_text_cursor (settings=settings@entry=0x5555555b8150) at libyelp/yelp-view.c:2094 #15 0x00007ffff7e327e3 in yelp_view_class_init (klass=0x5555555b6520) at libyelp/yelp-view.c:465 #16 yelp_view_class_intern_init (klass=0x5555555b6520) at libyelp/yelp-view.c:144 #17 0x00007ffff7fa6ef1 in g_type_class_ref () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00005555555565bc in get_object_types () at libyelp-scan.c:62 #19 main () at libyelp-scan.c:113 That's here: if (!AcceleratedBackingStore::checkRequirements()) { m_canUseHardwareAcceleration = false; return; } See also bug 156972 for a related problem already fixed 4 years ago.
Ok, so we're hitting the RELEASE_ASSERT_NOT_REACHED() in AcceleratedBackingStore::checkRequirements(), and the reason is that the PlatformDisplay type is neither Wayland nor X11, but WPE.
(In reply to Alberto Garcia from comment #1) > Ok, so we're hitting the RELEASE_ASSERT_NOT_REACHED() in > AcceleratedBackingStore::checkRequirements(), and the reason is that > the PlatformDisplay type is neither Wayland nor X11, but WPE. I think we can just remove that assert
Created attachment 395152 [details] Patch
Committed r259380: <https://trac.webkit.org/changeset/259380>
It looks like the Yelp build still crashes, different backtrace this time: (process:35799): Gtk-CRITICAL **: 13:40:20.270: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed ** (process:35799): WARNING **: 13:40:20.271: Unable to connect to dbus: Cannot autolaunch D-Bus without X11 $DISPLAY Unable to init server: Could not connect: Connection refused Segmentation fault Thread 1 "libyelp-scan" received signal SIGSEGV, Segmentation fault. 0x00007ffff335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at ./src/renderer-backend-egl.c:54 54 backend->base.interface->destroy(backend->base.interface_data); (gdb) bt #0 0x00007ffff335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at ./src/renderer-backend-egl.c:54 #1 0x00007ffff63bc8bb in WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() () at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:66 #2 0x00007ffff63bc8d9 in WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() () at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:67 #3 0x00007ffff7c59e27 in __run_exit_handlers (status=0, listp=0x7ffff7dd8718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #4 0x00007ffff7c59fda in __GI_exit (status=<optimized out>) at exit.c:139 #5 0x00007ffff7c42e12 in __libc_start_main (main= 0x555555556480 <main>, argc=1, argv=0x7fffffffdd78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdd68) at ../csu/libc-start.c:342 #6 0x0000555555557b7a in _start () at libyelp-scan.c:1025 So it seems that m_backend is null in the PlatformDisplayLibWPE destructor.
I confirm that checking for null in wpe_renderer_backend_egl_destroy() is enough to avoid the crash and fix the Yelp build, but perhaps the change should be in WebKit ?
I don't think we should create a PlatformDisplayLibWPE as fallback. We could fix it in PlatformDisplay::createPlatformDisplay() either: #if USE(WPE_RENDERER) -> #if USE(LIBWPE) or just move the block: #if USE(WPE_RENDERER) return PlatformDisplayLibWPE::create(); #elif PLATFORM(WIN) return PlatformDisplayWin::create(); #endif at the end of the function, right before the RELEASE_ASSERT_NOT_REACHED() Could you try any of these solutions, please?
(In reply to Carlos Garcia Campos from comment #7) > or just move the block: > > #if USE(WPE_RENDERER) > return PlatformDisplayLibWPE::create(); > #elif PLATFORM(WIN) > return PlatformDisplayWin::create(); > #endif > > at the end of the function, right before the RELEASE_ASSERT_NOT_REACHED() I confirm that this one works and fixes the problem. Do you want me to try the other one, or to prepare a patch with this one, or what?
Yes, please, just submit a patch with any of the solutions if you don't mind :-)
Created attachment 397668 [details] Patch
Committed r260750: <https://trac.webkit.org/changeset/260750>