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.