Bug 108581 - llvmpipe crashes using kms_swrast_dri.so
Summary: llvmpipe crashes using kms_swrast_dri.so
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-28 18:36 UTC by Stephan Hilb
Modified: 2019-09-18 18:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
backtrace: crashing thread (1.46 KB, text/plain)
2018-10-28 18:36 UTC, Stephan Hilb
Details
backtrace: calling thread (4.11 KB, text/plain)
2018-10-28 18:37 UTC, Stephan Hilb
Details
backtrace: another rendering thread (1.47 KB, text/plain)
2018-10-28 18:38 UTC, Stephan Hilb
Details
sway debug log (with egl and llvmpipe debug options) (23.22 KB, text/x-log)
2018-10-28 18:40 UTC, Stephan Hilb
Details
helgrind log (13.16 KB, text/x-log)
2018-11-10 18:02 UTC, Stephan Hilb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Hilb 2018-10-28 18:36:38 UTC
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
Comment 1 Stephan Hilb 2018-10-28 18:37:43 UTC
Created attachment 142247 [details]
backtrace: calling thread
Comment 2 Stephan Hilb 2018-10-28 18:38:42 UTC
Created attachment 142248 [details]
backtrace: another rendering thread
Comment 3 Stephan Hilb 2018-10-28 18:40:36 UTC
Created attachment 142249 [details]
sway debug log (with egl and llvmpipe debug options)
Comment 4 Roland Scheidegger 2018-10-29 15:26:18 UTC
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.
Comment 5 Stephan Hilb 2018-11-10 18:02:22 UTC
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.
Comment 6 GitLab Migration User 2019-09-18 18:33:37 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/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.