2011/12/22 Mathieu Desnoyers <comp...@krystal.dyndns.org>: > I've now splitted liblttng-ust into two libs: liblttng-ust-tracepoint > (dlopen'd by the application to register the tracepoints), and > liblttng-ust (which is used by the tracepoint probes, and talks to > lttng-sessiond). > > I've updated the README file in lttng-ust to specify that the tracepoint > probes should not be dlopen()'d. dlopen has just too many nasty > side-effects with TLS (grabbing a lock also taken in constructors is > a major one). Please use LD_PRELOAD or link the application directly > with the tracepoint probe .so. Even if I change the locking scheme > within liblttng-ust to play nicely with the dynamic linker mutex, the > whole thing would still be fragile due to the possibility to hit that > mutex from an active tracepoint (which could nest in various other > mutexes).
In my application, the probe activation problem came from the fact that the constructor was not carried on from the static library to the (dlopened) shared library. I changed the the static library to a shared one, and it worked. I reproduced this behavior on a minimalistic example. On this example, I also tried to activate the probes through LD_PRELOAD, it worked flawlessly. > Note that you can still dlopen() the file that is instrumented with > tracepoints (the file where you define e.g. TRACEPOINT_DEFINE and add > your tracepoint() statements). It's only the probe (with > TRACEPOINT_CREATE_PROBES defined) that cannot be dlopen'd. ok, I'll then try to use LD_PRELOAD and the new splitted libs on the main app, probably next week. Cheers -- Sébastien _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev