<div dir="ltr">Probably this is still some sort of interference between the wrapper and this android emulator while resolving symbols.<div><br></div><div>You should rebuild apitrace with cmake -DCMAKE_BUILD_TYPE=Debug to get debug symbols, and get stack traces with gdb.<div><div><br></div><div>But it's going to be hard to debug this remotely. Is this android emulator publicly available?</div><div><br></div><div><div><div>Jose<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 11:50 PM, Divick Kishore <span dir="ltr"><<a href="mailto:divick.kishore@gmail.com" target="_blank">divick.kishore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jose,<br>
with this patch it does proceed further and it seems it is<br>
able to lookup properly, but I am not yet sure how it is able to work.<br>
Nevertheless even with this patch, my application seems to crash in<br>
the wrapped libGL:<br>
<br>
apitrace: warning: caught signal 11<br>
apitrace: ignoring exception while tracing<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2f2645<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2f1a97<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2f0d17<br>
/lib/x86_64-linux-gnu/libpthread.so.0+0x1033f<br>
/lib/x86_64-linux-gnu/libc.so.6+0x97ff0<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2efd12<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2ebc7f<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x2eae7d<br>
streamer/apitrace/build/wrappers/libGL.so.1+0x21009a<br>
streamer/apitrace/build/wrappers/libGL.so.1: glDrawArrays+0x83<br>
../streamer/plugins/dist/lib/gstreamer-1.0/libGLES_V2_translator.so:<br>
glDrawArrays+0x132<br>
streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:<br>
_ZN21gl2_decoder_context_t6decodeEPvmP8IOStream+0x889<br>
streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:<br>
_ZN12RenderThread4MainEv+0x1b4<br>
streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:<br>
_ZN7osUtils6Thread11thread_mainEPv+0x10<br>
/lib/x86_64-linux-gnu/libpthread.so.0+0x8181<br>
/lib/x86_64-linux-gnu/libc.so.6: clone+0x6c<br>
?<br>
apitrace: info: taking default action for signal 11<br>
<br>
But the application proceeds beyond the point where the crash occurs<br>
without the apitrace. I am wondering if the issue is in my application<br>
or in apitrace?<br>
<br>
Thanks for your help,<br>
Cheers,<br>
Divick<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Nov 17, 2015 at 2:40 AM, José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com">jose.r.fonseca@gmail.com</a>> wrote:<br>
> Hmm. Not sure exactl what's happening.<br>
><br>
> Maybe the application is somehow dlopening libGL.so (which in this case is<br>
> the wrapper) with RTLD_LOCAL, which causes dl.so to also be opened with<br>
> RTLD_LOCAL, so `dlsym(RTLD_NEXT, "dlopen")` fails, as RTLD_NEXT will skip<br>
> local symbols. But if that's the case, how can the app dlopen libGL.so<br>
> without dl.so symbols being global?<br>
><br>
> See if the patch attached helps.<br>
><br>
> I plan to update apitrace to not intercept dlopen -- it causes more problems<br>
> than it solves.<br>
><br>
> Jose<br>
><br>
> On Mon, Nov 16, 2015 at 6:48 PM, Divick Kishore <<a href="mailto:divick.kishore@gmail.com">divick.kishore@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>> I am trying to dump traces for an application for which LD_PRELOAD<br>
>> mechnism cannot work (as it something similar to what android emulator<br>
>> does). Thus I am trying to trace it using glxtrace.so mechanism as<br>
>> mentioned in the docs. For some reason it gives error even before it<br>
>> loads the gl libs. It complains with:<br>
>><br>
>> apitrace: tracing to <path>/python3.4.63.trace<br>
>> apitrace: error: failed to look up real dlopen<br>
>> apitrace: error: couldn't find libGL.so<br>
>><br>
>> Looking at the sources I see that dlsym/dlopen themselves are wrapped<br>
>> and the actual lookup happens via glibc internal functions<br>
>> __libc_dlopen_mode and __libc_dlsym. Furthermore it is able to lookup<br>
>> dlsym via __libc_dlsym but when it calls this returned pointer with<br>
>> dlsym_ptr(handle, symbol), it returns a NULL pointer. Also I tried<br>
>> printing the and dlerror but it print "(null)".<br>
>><br>
>> I am not sure why is it unable to lookup the real dlopen.<br>
>><br>
>> I would appreciate any help.<br>
>> Thanks,<br>
>> Divick<br>
>> _______________________________________________<br>
>> apitrace mailing list<br>
>> <a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
>> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>