[lttng-dev] some troubles having lttgng-ust actually log something on a shared library

[Sébastien Barthélémy]

2011/12/22 Mathieu Desnoyers <compudj at krystal.dyndns.org>:
> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> [...]
>> > Maybe, but the program really hangs in such a case, and not in the other.
>>
>> Hrm, that's odd. It is never supposed to hang the program.
>>
>> >
>> > I have attached the two log files if you want to have a look.
>>
>> I'd bet this is caused by the work-around for "Linux kernels 2.6.33 to
>> 3.0 (with the exception of stable versions) do not support FUTEX_WAKE
>> on read-only memory mappings correctly. Please upgrade your kernel (fix
>> is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel
>> mainline).  LTTng-UST will use polling mode fallback. (in
>> wait_for_sessiond() at lttng-ust-comm.c:569)"

I had the same idea, and upgraded my ubuntu system to the last release
in order to try on a newer kernel.

My previous kernel was
Linux sbarthelemy-de 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11
03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

My new one is
Linux sbarthelemy-de 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21
20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

With the new ubuntu release, ld behaviour changed a lot, and my
example Makefile ceased to build (background here:
http://wiki.debian.org/ToolChain/DSOLinking)

Attached is a new Makefile which produces successful builds, without
ust hangs, on my new system.

>> I'll try to reproduce your issue here.
>
> So it can be reproduced on a system with up-to-date kernel.

Idem here with my new kernel.

> I've been able to identify that the hang is caused by a call to libuuid from
> liblttng-ust. It hangs when trying to access a TLS variable within
> libuuid (which is protected by a mutex, which I guess is uninitialized).
> I've tried to add just "-luuid" to the application and it works fine.

This workaround works here too.

Thank you for investigating this.

By the way, I found why lttng-ust was not working on a my main
application: the instrumented code and the probes were included in the
application through several levels of libraries (both static and
dynamic), and, in the process, the
the constructor from include/lttng/ust-tracepoint-event.h was lost. So
the probe were
never activated.

The "just registered probe..." message you just added would probably have helped
me figure it out faster. Good idea adding it.

I'll try to come with a clean solution to build and activate the probes here
(I'll look at the LD_PRELOAD example too).

Best regards
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 536 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20111222/57d509fe/attachment.obj>