[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #18 from shinji.suzuki at gmail.com ---
> Looks like glDeleteSync directly calls (or is a macro of?)
I thought that was the case because I got this stack trace;
(gdb) where
#0  st_delete_sync_object (ctx=0x863890, obj=0x7fffe8001320)
    at state_tracker/st_cb_syncobj.c:62
#1  0x0000000000466137 in Fence::~Fence (this=0x7fffe80012a0, 
    __in_chrg=<optimized out>)
   at /home/suzuki/src/photron/ndro2016/gl_fence.cpp:31

gl_fence.cpp:31 is the call site of glDeleteSync().
But if I set break point at _mesa_DeleteSync, then I get this.

#0  _mesa_DeleteSync (sync=0x7fffe80017e0) at main/syncobj.c:241
#1  0x0000000000466137 in Fence::~Fence (this=0x7fffe8001760,
    __in_chrg=<optimized out>)
    at /home/suzuki/src/photron/ndro2016/gl_fence.cpp:31

If I step into st_delete_sync_object(), I get same trace as the first one.
Looks like as if gdb is not showing correct call trace while the program is
executing st_delete_sync_object().

The bottom line is; glDeleteSync() object likely calls st_delete_sync_object
not directly but via _mesa_DeleteSync, which does perform reference counting on
the sync-object.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161015/e98fdf19/attachment-0001.html>