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 <jfons...@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.wo...@intel.com > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
