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