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

[Mathieu Desnoyers]

* 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'll try to reproduce your issue here.

So it can be reproduced on a system with up-to-date 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. So
it really looks like we have a linker constructor execution order issue
here. One key point here is the "dlopen" done in a constructor inserted
by tracepoint.h.

Enough for tonight, more to come soon,

Best regards,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com