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" <[email protected]> > To: [email protected], "mathieu desnoyers" > <[email protected]>, [email protected] > 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 _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
