Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: paul_woegerer@mentor.com (Paul Woegerer)
Subject: [lttng-dev] [PATCH lttng-ust 0/3] Solve remaining issues with base-address-state tracing
Date: Thu, 28 Nov 2013 13:26:51 +0100	[thread overview]
Message-ID: <1385641614-18806-1-git-send-email-paul_woegerer@mentor.com> (raw)

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




             reply	other threads:[~2013-11-28 12:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 12:26 Paul Woegerer [this message]
2013-11-28 12:26 ` [lttng-dev] [PATCH lttng-ust 1/3] Integrate base-address statedump into lttng-ust Paul Woegerer
2013-11-28 12:26 ` [lttng-dev] [PATCH lttng-ust 2/3] Fix: baddr_statedump deadlock with JUL tracing Paul Woegerer
2013-11-28 12:26 ` [lttng-dev] [PATCH lttng-ust 3/3] Allow suppressing of base-address-state tracing Paul Woegerer
2013-11-28 15:59 ` [lttng-dev] [PATCH lttng-ust 0/3] Solve remaining issues with " Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1385641614-18806-1-git-send-email-paul_woegerer@mentor.com \
    --to=paul_woegerer@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox