I'm setting up a CI pipeline for my wlroots based Wayland compositor, Cage (https://github.com/hjdskes/cage). On the CI server, I execute Cage with wlroots' headless backend and then run Cage with several sanitizers.
In this process, I came across a "deadly signal" in the address sanitizer, the trace of which is can be found at https://builds.sr.ht/~hjdskes/job/56792#task-gcc-64.
The manifest with the build definition can be found at https://builds.sr.ht/api/jobs/56792/manifest. In short, this runs on an ArchLinux image with mesa 19.0.2 (recompiled to include debug symbols), with wlroots 0.5.0 and Cage commit c52e82e9a8a931bbd35126fbfef7ee78f2da3c3d.
If there is any more information I can provide, please let me know.
I have looked at the trace. The source code line and struct offset imply that dri2_egl_display::image_driver is NULL in dri2_surfaceless_create_surface function. Of note is also the fact that a software renderer is used:
libEGL warning: No hardware driver found, falling back to software rendering
I see the following piece of code in dri2_wl_create_window_surface:
createNewDrawable = dri2_dpy->image_driver->createNewDrawable;
else if (dri2_dpy->dri2)
createNewDrawable = dri2_dpy->dri2->createNewDrawable;
createNewDrawable = dri2_dpy->swrast->createNewDrawable;
Shouldn't the surfaceless variant also try all three instead of relying on image_driver not being NULL?
Note that I am not overly familiar with how dri works, so I might be wrong.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/174.