| Summary: | Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | James Legg <jlegg> |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Apitrace reproducing issue
Valgrind output when replaying trace |
||
Created attachment 126725 [details]
Valgrind output when replaying trace
Valgrind reports a use after free error when the unmap occurs.
You like to live dangerously :) I can reproduce and will look into this, thank you for the clean report! A candidate fix is here: https://patchwork.freedesktop.org/series/12982/ A can confirm that patch series fixes the issue. Fixed in Mesa master (commit e56e1f8119f28eebbe6fbe7040c80a6dd884f5fd). |
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.
Created attachment 126724 [details] Apitrace reproducing issue The following sequence of events cause a crash on radeonsi: 1. Create two contexts in the same share group 2. In one of the contexts, create and map a buffer. Then delete that context. 3. Create another context in the share group 4. Cause the buffer to be unmapped in the new context (either explicitly with glUnmapBuffer/glUnmapNamedBuffer or implicitly via glDeleteBuffers). The attached apitrace reproduces the issue when using an AMD R9 270, unless environment variable LIBGL_ALWAYS_SOFTWARE is set to 1. I reproduced this using Mesa git 36f0f0318275f65f8744ec6f9471702e2f58e6d5 and the 12.0.3 release on x86_64 Fedora 24. My OpenGL renderer string is Gallium 0.4 on AMD PITCAIRN (DRM 2.45.0 / 4.7.2-201.fc24.x86_64, LLVM 3.9.0).