On 5/29/26 1:18 PM, Alexander Kanavin wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Fri, 29 May 2026 at 18:47, Quan Sun via lists.openembedded.org
<[email protected]> wrote:
The QEMU 11.0 changed its GL display initialization sequence. On
headless build hosts (no Wayland, no proper GPU), QEMU 10.x would
silently fall through and start, while QEMU 11.0 now probes more
aggressively:
1. Tries GLX/DRI3 → fails (glx: failed to create dri3 screen, failed to
load driver: vgem)
2. Tries Wayland/EGL → crashes (the segfault in eglInitialize →
wl_proxy_create_wrapper)
It's not a race — it's a deterministic crash because QEMU 11.0's new
init path tries
to call into Wayland client code on a host where Wayland isn't running,
and that code
path hits a NULL pointer or invalid state in wl_proxy_create_wrapper.
Still, the upgrade itself may be fine — all actual QEMU
functionality works (685/686 tests pass). The single failure is in
test_testimage_virgl_gtk_sdl, which tests hardware-accelerated GL
rendering into a GTK
/SDL window — something that doesn't work on headless CI hosts
regardless, and QEMU
11.0 just crashes harder than 10.x did when it fails. The test itself
may be a candidate
for removal/rework.
qemu 10.x does not crash, or silently fail, and it is able to open sdl
and gtk windows even on headless hosts without GPU. Yocto CI is
specifically set up to support it: it's runing Tiger VNC server that X
clients (such as qemu) can connect to, and qemu is using mesa's
llvmpipe renderer which does not require a physical GPU.
Are you using AI to write out argumentation here as well, or are these
your own thoughts? Please be clear about this. I'd be happy to correct
you, but I would not want to spend too much time time correcting AI,
because I don't think it is going to provide sudden helpful insights.
To get to the bottom of it, someone needs to set up a gdb session and
step through the code of 11.x and 10.x initializations, finding out
why one falls through to the crashing wayland step, and the other does
not. AI is not capable of doing that kind of reproducing the issue,
and then debugging it, not yet at least.
Alex
Hi Alex,
Because I haven't got much info when it failed, and through these email
exchanges I know more and more about what's happening - you guys know
more, although AI was used in analyzing some of the behaviors, I'm not
blind to trust it - sorry that it bothered you. But apparently QEMU 11.0
changed its GL initialization and now tries Wayland/EGL paths before (or
instead of) the GLX/X11 path that worked with 10.x. On these CI hosts
there's no Wayland, so it crashes when it shouldn't be probing Wayland
at all. We'll investigate why this is the case.
Thanks,
Quan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#237772):
https://lists.openembedded.org/g/openembedded-core/message/237772
Mute This Topic: https://lists.openembedded.org/mt/119486545/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
