[lttng-dev] [PATCH lttng-ust 0/3] Solve remaining issues with base-address-state tracing
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Thu Nov 28 10:59:18 EST 2013
Merged patches 1 and 3, not 2. I also did another commit to move files around and
simplify things.
We need to discuss the deadlock fix more thoroughly.
Thanks,
Mathieu
----- Original Message -----
> From: "Paul Woegerer" <paul_woegerer at mentor.com>
> To: lttng-dev at lists.lttng.org, "mathieu desnoyers" <mathieu.desnoyers at efficios.com>, dgoulet at efficios.com
> Sent: Thursday, November 28, 2013 1:26:51 PM
> Subject: [PATCH lttng-ust 0/3] Solve remaining issues with base-address-state tracing
>
> This patch series addresses the remaining issues that were reported against
> base-address-state tracing. Base-address-state tracing is now fully
> integrated
> into lttng-ust (no separate shared object anymore).
>
> Users that would like to suppress the generation of ust_baddr_statedump
> events
> entirely can now use environment variable
> LTTNG_UST_WITHOUT_BADDR_STATEDUMP=1.
>
> The deadlock in combination with JUL tracing is also fixed now. It was caused
> by the fact that JUL tracing causes the static constructor of lttng-ust to be
> called in the context of dlopen:
>
> To setup JUL tracing the JVM executes:
>
> System.loadLibrary("lttng-ust-jul-jni");
>
> This effectively dlopen's lttng-ust-jul-jni.so.0 and that will cause the
> static
> ctor of lttng-ust to get executed. Now if the completion of the execution of
> the lttng-ust ctor depends on someone that tries to acquire a lock on glibc's
> dl_load_lock we run into a deadlock because the lock is already hold as a
> side
> effect of the dlopen that was initiated by the JVM to load
> "lttng-ust-jul-jni".
> But exactly that happened when base-address-state tracing tries to generate
> ust_baddr_statedump events on session-enable (e.g. calling dladdr or emitting
> a
> tracepoint all try to acquire the dl_load_lock).
>
> By making the ust_baddr_statedump happen a "little later" so that it cannot
> block the completion of the static ctor anymore, the deadlock is prevented.
> Once we know the static ctor will complete for sure we also know that the JVM
> initiated dlopen that called the static ctor will complete. At that point is
> is again safe to use calls that involve acquiring dl_load_lock. Making the
> statedump happen a "little later" is implemented by patch:
>
> Fix: baddr_statedump deadlock with JUL tracing
>
>
> Paul Woegerer (3):
> Integrate base-address statedump into lttng-ust
> Fix: baddr_statedump deadlock with JUL tracing
> Allow suppressing of base-address-state tracing
>
> Makefile.am | 3 +-
> liblttng-ust-baddr/Makefile.am | 18 +----
> liblttng-ust-baddr/lttng-ust-baddr.c | 34 ++--------
> liblttng-ust-baddr/lttng-ust-baddr.h | 22 +++++++
> liblttng-ust-baddr/ust_baddr_statedump.h | 2 +-
> liblttng-ust-dl/Makefile.am | 5 +-
> .../ust_baddr.c | 0
> .../ust_baddr.h | 0
> liblttng-ust-dl/ustdl.c | 76
> ++++++----------------
> liblttng-ust/Makefile.am | 1 +
> liblttng-ust/lttng-ust-comm.c | 50 ++------------
> 11 files changed, 63 insertions(+), 148 deletions(-)
> create mode 100644 liblttng-ust-baddr/lttng-ust-baddr.h
> rename {liblttng-ust-baddr => liblttng-ust-dl}/ust_baddr.c (100%)
> rename {liblttng-ust-baddr => liblttng-ust-dl}/ust_baddr.h (100%)
>
> --
> 1.8.4
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list