Error with dlopen on linux 64 bit

[Divick Kishore]

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
>
>