[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