Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [PATCH lttng-ust 0/3] Solve remaining issues with base-address-state tracing
Date: Thu, 28 Nov 2013 15:59:18 +0000 (UTC)	[thread overview]
Message-ID: <1334310693.77201.1385654358360.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1385641614-18806-1-git-send-email-paul_woegerer@mentor.com>

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@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



      parent reply	other threads:[~2013-11-28 15:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 12:26 Paul Woegerer
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 ` Mathieu Desnoyers [this message]

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=1334310693.77201.1385654358360.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.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