--- Comment #18 from ---
> 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.
mesa-dev mailing list

Reply via email to