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: RESOLVED MOVED
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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-21 12:09 UTC by Jente Hidskes
Modified: 2019-09-18 18:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Jente Hidskes 2019-04-21 12:09:58 UTC
Hello,

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;
   else
      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.
Comment 2 GitLab Migration User 2019-09-18 18:09:15 UTC
-- 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.


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.