https://bugs.freedesktop.org/show_bug.cgi?id=98172
Bug ID: 98172
Summary: Concurrent call to glClientWaitSync results in
segfault in one of the waiters.
Product: Mesa
Version: 11.2
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
Assignee: dri-devel at lists.freedesktop.org
Reporter: shinji.suzuki at gmail.com
QA Contact: dri-devel at lists.freedesktop.org
In my app, a fence is created in Thread-A and it gets passed to Thread-B and
Thread-C to be waited upon. (Each thread has its own context.)
Thread-A issues the call, fence = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE,
0).
Thread-B and C issue the call, glClientWaitSync(fence,
GL_SYNC_FLUSH_COMMANDS_BIT, GL_TIMEOUT_IGNORED);
Most of the time, wait in both clients succeed but occasionally one of them
generates segfault. Upon inspection of generated core, it turned out so->fence
in the expression "&so->fence" at line 113 in
src/mesa/state_tracker/st_cb_syncobj.c is NULL, which should be causing the
segfault down the call chain through screen->fence_reference. I think there is
race in executing the code block. If I introduce a mutex in my app with which
to avoid concurrent call to glClientWaitSync, I don't observe segfault
happening.
Here is the snippet of code in question from st_cb_syncobj.c:
if (so->fence &&
screen->fence_finish(screen, so->fence, timeout)) {
screen->fence_reference(screen, &so->fence, NULL);
so->b.StatusFlag = GL_TRUE;
}
My environment is;
Ubuntu 16.04 LTS
Linux a7da 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
libgl1-mesa-dri:amd64 / 11.2.0-1ubuntu2.2
Radeon HD3300
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/410e7b5e/attachment.html>
