Problem replaying trace on Mesa 10.1.4

José Fonseca jose.r.fonseca at gmail.com
Tue May 27 05:46:02 PDT 2014


On Tue, May 27, 2014 at 1:21 PM, Alexander Monakov <amonakov at ispras.ru>wrote:

>
>
> On Tue, 27 May 2014, io.github.apitrace at io7m.com wrote:
> > > Actually I see why the behavior changed for you; you've probably
> updated from
> > > apitrace 4.0 to 5.0; 4.0 did not supply the application-requested GL
> profile
> > > version to the driver: https://github.com/apitrace/apitrace/issues/176
> > >
> > > So, disregard what I said about Mesa/Xorg before; the issue and the
> behavior
> > > change is entirely on apitrace side.  The fix, I believe, would be to
> make X
> > > protocol errors not fatal in the replayer.
> >
> > Ok, thanks. So, is it just a case of waiting for a fix now? I don't
> > think I know enough about apitrace's implementation to correctly fix
> > this myself.
>
> You should be able to fix it yourself if you want; in retrace/glws_glx.cpp,
> into init(void) add a call to XSetErrorHandler with a handler function
> (that
> you'll need to write).  The handler function may be empty, as the
> corresponding waffle patch does:
> http://lists.freedesktop.org/archives/waffle/2012-November/000125.html
>
> (but you can also print error messages with XGetErrorText).
>
> See "man XSetErrorHandler" and "man XErrorEvent" for details.
>
> Alexandre


Although I believe the right fix is to not attempt replaying failed calls
(fix pushed as
https://github.com/apitrace/apitrace/commit/7cdaf0210385b3189512d8956c9931e2eabdc858)
, I also think that having our own X error handler is a good idea too.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20140527/8f1b8414/attachment.html>


More information about the apitrace mailing list