Since the Debian package got updated to 2.35 some of the Ubuntu autopkgtests have been failing on arm64, trying to start the demo browser it seems webkitgtk is indeed buggy on that architecture Trying with the current 2.35.90 package $ /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/MiniBrowser libEGL warning: DRI3: failed to query the version libEGL warning: DRI2: failed to authenticate (WebKitWebProcess:1316379): Gdk-ERROR **: 07:55:56.794: The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 193 error_code 1 request_code 155 (unknown) minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) ** (MiniBrowser:1316360): WARNING **: 07:55:57.176: WebProcess CRASHED Getting a backtrace is a bit tricky because the VM is limited in memory and it fails to complete the gdb session Downgradeing to 2.34 the browser works fine and there is no DRI2 or 3 warnings
Alright, after adding some swap to the instance, backtrace from doing $ GDK_SYNCHRONIZE=1 /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/MiniBrowser and using $ gdb /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess cdump (is setting the env for the browser enough to have it for the rendering process as well or would something else be needed?) Core was generated by `/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 12 15'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 __pthread_kill_implementation (threadid=281473526416608, signo=signo@entry=5, no_tid=no_tid@entry=0) --Type <RET> for more, q to quit, c to continue without paging-- at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. [Current thread is 1 (Thread 0xffffa98e44e0 (LWP 1317303))] (gdb) bt #0 __pthread_kill_implementation (threadid=281473526416608, signo=signo@entry=5, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x0000ffffa9bc3054 in __pthread_kill_internal (signo=5, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x0000ffffa9b7e47c in __GI_raise (sig=5) at ../sysdeps/posix/raise.c:26 #3 0x0000ffffa978090c in g_log_writer_default () from /lib/aarch64-linux-gnu/libglib-2.0.so.0 #4 0x0000ffffa977c6c8 in g_log_structured_array () from /lib/aarch64-linux-gnu/libglib-2.0.so.0 #5 0x0000ffffa977c880 in g_log_structured_standard () from /lib/aarch64-linux-gnu/libglib-2.0.so.0 #6 0x0000ffffa7255da0 in _gdk_x11_display_error_event (error=0xffffdc9cdf88, display=0xaaaad88a70e0) at x11/../../../../../gdk/x11/gdkdisplay-x11.c:2766 #7 _gdk_x11_display_error_event (error=0xffffdc9cdf88, display=0xaaaad88a70e0) at x11/../../../../../gdk/x11/gdkdisplay-x11.c:2711 #8 gdk_x_error (error=0xffffdc9cdf88, xdisplay=0xaaaad888df10) at x11/../../../../../gdk/x11/gdkmain-x11.c:296 #9 gdk_x_error (xdisplay=0xaaaad888df10, error=0xffffdc9cdf88) at x11/../../../../../gdk/x11/gdkmain-x11.c:258 #10 0x0000ffffa5e92388 in _XError () from /lib/aarch64-linux-gnu/libX11.so.6 #11 0x0000ffffa5e924b4 in ?? () from /lib/aarch64-linux-gnu/libX11.so.6 #12 0x0000ffffa5e92568 in ?? () from /lib/aarch64-linux-gnu/libX11.so.6 #13 0x0000ffffa5e92630 in _XEventsQueued () from /lib/aarch64-linux-gnu/libX11.so.6 #14 0x0000ffffa5e92914 in _XGetRequest () from /lib/aarch64-linux-gnu/libX11.so.6 #15 0x0000ffffa5e6b3e0 in XResizeWindow () from /lib/aarch64-linux-gnu/libX11.so.6 #16 0x0000ffffaaac151c in WebKit::AcceleratedSurfaceX11::hostResize () at ./Source/WebKit/WebProcess/WebPage/gtk/AcceleratedSurfaceX11.cpp:159 #17 WebKit::AcceleratedSurfaceX11::hostResize () at ./Source/WebKit/WebProcess/WebPage/gtk/AcceleratedSurfaceX11.cpp:153 #18 0x0000ffffaaabcd5c in WebKit::LayerTreeHost::sizeDidChange () at ./Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:239 #19 0x0000ffffaaabcf1c in WebKit::DrawingAreaCoordinatedGraphics::updateBackingStoreState () at ./Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:427 #20 0x0000ffffaa4e9f78 in IPC::callMemberFunctionImpl<WebKit::DrawingArea, void (WebKit::DrawingArea::*)(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&), std::tuple<unsigned long, bool, float, WebCore::IntSize, WebCore::IntSize>, 0ul, 1ul, 2ul, 3ul, 4ul> () at ./Source/WebKit/Platform/IPC/HandleMessage.h:125 #21 IPC::callMemberFunction<WebKit::DrawingArea, void (WebKit::DrawingArea::*)(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&), std::tuple<unsigned long, bool, float, WebCore::IntSize, WebCore::IntSize>, std::integer_sequence<unsigned long, 0ul, 1ul, 2ul, 3ul, 4ul> > () at ./Source/WebKit/Platform/IPC/HandleMessage.h:131 #22 IPC::handleMessage<Messages::DrawingArea::UpdateBackingStoreState, WebKit::DrawingArea, void (WebKit::DrawingArea::*)(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&)> () at ./Source/WebKit/Platform/IPC/HandleMessage.h:196 #23 0x0000ffffaa6a3bc8 in IPC::MessageReceiverMap::dispatchMessage () at ./Source/WebKit/Platform/IPC/MessageReceiverMap.cpp:129 #24 0x0000ffffaa919c24 in WebKit::WebProcess::didReceiveMessage () at ./Source/WebKit/WebProcess/WebProcess.cpp:902 #25 0x0000ffffaa69c648 in IPC::Connection::dispatchMessage () at ./Source/WebKit/Platform/IPC/Connection.cpp:1137 #26 0x0000ffffaa69dc04 in IPC::Connection::dispatchOneIncomingMessage () at ./Source/WebKit/Platform/IPC/Connection.cpp:1206 #27 0x0000ffffa935e4e8 in WTF::Function<void ()>::operator()() const () at ./Source/WTF/wtf/Function.h:82 ...
adding the libx11 frames with debug symbols #10 0x0000ffffa5e92388 in _XError (dpy=dpy@entry=0xaaaad888df10, rep=rep@entry=0xaaaad8a17300) at ../../src/XlibInt.c:1503 #11 0x0000ffffa5e924b4 in handle_error (dpy=0xaaaad888df10, err=0xaaaad8a17300, in_XReply=<optimized out>) at ../../src/xcb_io.c:207 #12 0x0000ffffa5e92568 in handle_response (dpy=dpy@entry=0xaaaad888df10, response=0xaaaad8a17300, in_XReply=<optimized out>) at ../../src/xcb_io.c:394 #13 0x0000ffffa5e92630 in _XEventsQueued (mode=<optimized out>, dpy=0xaaaad888df10) at ../../src/xcb_io.c:433 #14 _XEventsQueued (dpy=0xaaaad888df10, mode=mode@entry=1) at ../../src/xcb_io.c:414 #15 0x0000ffffa5e926c4 in _XFlush (dpy=<optimized out>) at ../../src/xcb_io.c:602 #16 0x0000ffffa5e92914 in _XGetRequest (dpy=0xaaaad888df10, type=<optimized out>, len=20) at ../../src/XlibInt.c:1787 #17 0x0000ffffa5e6b3e0 in XResizeWindow (dpy=0xaaaad888df10, w=73400324, width=1024, height=730) at ../../src/ChWindow.c:42
(In reply to seb128 from comment #1) > (is setting the env for the browser enough to have it for the rendering > process as well or would something else be needed?) Yes, that is enough. Thanks for the good backtrace. I don't have any grand ideas as to what is going wrong, though. If I needed to solve this bug, I would probably try to either (a) bisect it, which could be pretty frustrating to do depending on how convenient your access to this instance is, or (b) add a bunch of printfs to the code and hope they reveal something obviously wrong.
After debugging bug #238513 it occurred to us that one 'detail' is that Ubuntu is building webkitgtk without WPE at the moment and it had been mentioned that Debian also saw issues on arm64 last time they disabled WPE, so that might be an issue specific to that codepath