Created attachment 142246 [details] backtrace: crashing thread Running sway on GMA500 crashes llvmpipe. See attached backtrace and log for details. Doesn't crash with `LP_NUM_THREADS=0` or `LP_NUM_THREADS=1`, so maybe a threading issue? Might be related to #94522
Created attachment 142247 [details] backtrace: calling thread
Created attachment 142248 [details] backtrace: another rendering thread
Created attachment 142249 [details] sway debug log (with egl and llvmpipe debug options)
Looks like the buffer disappeared when it still had pending rendering commands to it (in this case, a clear command). I think this happens because these (kms) surfaces aren't allocated within llvmpipe itself, so there's no refcounting there and if those externally allocated surfaces are freed (externally) subsequent access will result in segfaults (valgrind possibly could shed some more light on it, if it still triggers with that). I'm not quite sure though where the root cause actually is, I think "something" needs to make sure that before the surfaces are destroyed that the renderer is really done with it.
Created attachment 142425 [details] helgrind log Sadly running with valgrind doesn't trigger the crash, but `--tool=helgrind` however gives some useful info on potential race conditions. The warnings for `lp_rast.c` seem interesting.
-- 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/249.
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.