<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Some Unity games fail assertion on startup in glXCreateContextAttribsARB"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99781#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Some Unity games fail assertion on startup in glXCreateContextAttribsARB"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99781">bug 99781</a>
from <span class="vcard"><a class="email" href="mailto:rstrode@redhat.com" title="Ray Strode [halfline] <rstrode@redhat.com>"> <span class="fn">Ray Strode [halfline]</span></a>
</span></b>
<pre>so looking a few stack frames up I see this:
err = xcb_request_check(c, cookie);•
if (err != NULL) {•
gc->vtable->destroy(gc);•
gc = NULL;•
•
__glXSendErrorForXcb(dpy, err);•
free(err);•
}•
and then __glXSendErrorForXcb does this:
void•
__glXSendErrorForXcb(Display * dpy, const xcb_generic_error_t *err)•
{•
xError error;•
…
error.sequenceNumber = err->sequence;•
…
_XError(dpy, &error);•
…
}•
So we see the sequence number comes from before a destroy hook which calls into
the driver. I guess it's possible (maybe?) that the hook is generating
protocol that updates last_request_read.
You could try reordering the gc->vtable->destroy(gc); after the
glXSendErrorForXcb and see if that fixes it.
If that doesn't work you could set a hardware watchpoint on (((struct
_XDisplay*)dpy)->last_request_read that just prints a backtrace and continues,
so you could see what's updating the last_request_read out from under it. If
that changes timing too much, you could put backtrace() into arrays in
X_DPY_SET_LAST_REQUEST_READ() and backtrace_symbols from gdb when it tanks.</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>