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
pgpJYhYGV47X5.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev