Error with dlopen on linux 64 bit

[José Fonseca]

Probably this is still some sort of interference between the wrapper and
this android emulator while resolving symbols.

You should rebuild apitrace with cmake -DCMAKE_BUILD_TYPE=Debug to get
debug symbols, and get stack traces with gdb.

But it's going to be hard to debug this remotely.  Is this android emulator
publicly available?

Jose

On Mon, Nov 16, 2015 at 11:50 PM, Divick Kishore <divick.kishore at gmail.com>
wrote:

> Hi Jose,
>             with this patch it does proceed further and it seems it is
> able to lookup properly, but I am not yet sure how it is able to work.
> Nevertheless even with this patch, my application seems to crash in
> the wrapped libGL:
>
> apitrace: warning: caught signal 11
> apitrace: ignoring exception while tracing
> streamer/apitrace/build/wrappers/libGL.so.1+0x2f2645
> streamer/apitrace/build/wrappers/libGL.so.1+0x2f1a97
> streamer/apitrace/build/wrappers/libGL.so.1+0x2f0d17
> /lib/x86_64-linux-gnu/libpthread.so.0+0x1033f
> /lib/x86_64-linux-gnu/libc.so.6+0x97ff0
> streamer/apitrace/build/wrappers/libGL.so.1+0x2efd12
> streamer/apitrace/build/wrappers/libGL.so.1+0x2ebc7f
> streamer/apitrace/build/wrappers/libGL.so.1+0x2eae7d
> streamer/apitrace/build/wrappers/libGL.so.1+0x21009a
> streamer/apitrace/build/wrappers/libGL.so.1: glDrawArrays+0x83
> ../streamer/plugins/dist/lib/gstreamer-1.0/libGLES_V2_translator.so:
> glDrawArrays+0x132
> streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:
> _ZN21gl2_decoder_context_t6decodeEPvmP8IOStream+0x889
> streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:
> _ZN12RenderThread4MainEv+0x1b4
> streamer/plugins/dist/lib/gstreamer-1.0/libgstcz.so:
> _ZN7osUtils6Thread11thread_mainEPv+0x10
> /lib/x86_64-linux-gnu/libpthread.so.0+0x8181
> /lib/x86_64-linux-gnu/libc.so.6: clone+0x6c
> ?
> apitrace: info: taking default action for signal 11
>
> But the application proceeds beyond the point where the crash occurs
> without the apitrace. I am wondering if the issue is in my application
> or in apitrace?
>
> Thanks for your help,
> Cheers,
> Divick
>
>
> On Tue, Nov 17, 2015 at 2:40 AM, José Fonseca <jose.r.fonseca at gmail.com>
> wrote:
> > Hmm. Not sure exactl what's happening.
> >
> > Maybe the application is somehow dlopening libGL.so (which in this case
> is
> > the wrapper) with RTLD_LOCAL, which causes dl.so to also be opened with
> > RTLD_LOCAL, so `dlsym(RTLD_NEXT, "dlopen")` fails, as RTLD_NEXT will skip
> > local symbols.  But if that's the case, how can the app dlopen libGL.so
> > without dl.so symbols being global?
> >
> > See if the patch attached helps.
> >
> > I plan to update apitrace to not intercept dlopen -- it causes more
> problems
> > than it solves.
> >
> > Jose
> >
> > On Mon, Nov 16, 2015 at 6:48 PM, Divick Kishore <
> divick.kishore at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>     I am trying to dump traces for an application for which LD_PRELOAD
> >> mechnism cannot work (as it something similar to what android emulator
> >> does). Thus I am trying to trace it using glxtrace.so mechanism as
> >> mentioned in the docs. For some reason it gives error even before it
> >> loads the gl libs. It complains with:
> >>
> >> apitrace: tracing to  <path>/python3.4.63.trace
> >> apitrace: error: failed to look up real dlopen
> >> apitrace: error: couldn't find libGL.so
> >>
> >> Looking at the sources I see that dlsym/dlopen themselves are wrapped
> >> and the actual lookup happens via glibc internal functions
> >> __libc_dlopen_mode and __libc_dlsym. Furthermore it is able to lookup
> >> dlsym via __libc_dlsym but when it calls this returned pointer with
> >> dlsym_ptr(handle, symbol), it returns a NULL pointer. Also I tried
> >> printing the and dlerror but it print "(null)".
> >>
> >> I am not sure why is it unable to lookup the real dlopen.
> >>
> >> I would appreciate any help.
> >> Thanks,
> >> Divick
> >> _______________________________________________
> >> apitrace mailing list
> >> apitrace at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/apitrace
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20151117/56f17632/attachment-0001.html>