[Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines

[Jose Fonseca]

I expected that when one sets TRACE_LIBGL env var with the path for the true libGL.so.1, then apitrace wouldn't be picking up symbols the overlay -- it would be taking symbols only from the true libGL.so, there avoiding infinite recursion.

Jose

----- Original Message -----
> Jose Fonseca <jfonseca at vmware.com> writes:
> > I see.  But one can use apitrace through LD_LIBRARY_PATH instead of
> > LD_PRELOAD. Steam is not the first app to have issues with LD_PRELOAD.
> 
> I spend some time looking at this issue today.
> 
> First, things aren't as bad as I had first thought. I had
> misunderstood the original report thinking that the Steam overlay made
> it so that no Steam games could be traced. But in fact, it's easy to
> trace a Steam game with "apitrace trace"—the only trick is to ensure
> that LD_PRELOAD does not include gamoverlayrenderer.so.
> 
> But, yes, there's definitely a failure if one actually does want to
> trace the operation of the overlay itself.
> 
> And switching from LD_PRELOAD to LD_LIBRARY_PATH for apitrace didn't
> fix things in my experiments. Regardless of the mechanism for invoking
> apitrace, I found the same behavior: If both apitrace and
> gameoverlayrenderer are loaded then the game will segfault. The crash
> is from infinite mutual recursion as the two wrappers continue to call
> into each others functions.


> I don't think it should be too hard to get this to work, (though it
> may require a source change to the Steam overlay). I'll do some more
> experiments tomorrow and see if I can't make a concrete recommendation
> to be able to give to Valve as a bug report.
> 
> And, obviously, if there's something we can do to make apitrace more
> robust here, I'll submit that change as well.
> 
> -Carl
> 
> --
> carl.d.worth at intel.com
>