[Mesa-dev] [Bug 99781] Some Unity games fail assertion on startup in glXCreateContextAttribsARB

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Ray Strode [halfline] <rstrode at redhat.com> ---
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.

-- 
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/20170630/85779474/attachment.html>