<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters."
href="https://bugs.freedesktop.org/show_bug.cgi?id=98172#c18">Comment # 18</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters."
href="https://bugs.freedesktop.org/show_bug.cgi?id=98172">bug 98172</a>
from <span class="vcard"><a class="email" href="mailto:shinji.suzuki@gmail.com" title="shinji.suzuki@gmail.com">shinji.suzuki@gmail.com</a>
</span></b>
<pre><span class="quote">> Looks like glDeleteSync directly calls (or is a macro of?)</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>