Bug 110479 - AddressSanitizer:DEADLYSIGNAL in src/egl/drivers/dri2/platform_surfaceless.c:139
Summary: AddressSanitizer:DEADLYSIGNAL in src/egl/drivers/dri2/platform_surfaceless.c:139
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL/Wayland (show other bugs)
Version: 19.0
Hardware: Other Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact: mesa-dev
Depends on:
Reported: 2019-04-21 12:09 UTC by Jente Hidskes
Modified: 2019-04-22 12:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Jente Hidskes 2019-04-21 12:09:58 UTC

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.
Comment 1 Gustaw Smolarczyk 2019-04-22 12:58:40 UTC
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:

   if (dri2_dpy->image_driver)
      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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.