[lttng-dev] [PATCH lttng-tools] Fix: sessiond: Consolidate key hash generation
add_unique_ust_app_event will create the same key hash
for both --loglevel and --loglevel-only, resulting in:
add_unique_ust_app_event: Assertion `node_ptr == >node.node' failed.
Signed-off-by: Mikael Beckius
---
src/bin/lttng-sessiond/ust-app.cpp | 16 +++-
src/bin/lttng-sessiond/ust-app.hpp | 7 ---
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/bin/lttng-sessiond/ust-app.cpp
b/src/bin/lttng-sessiond/ust-app.cpp
index b9091424b..f34b17d05 100644
--- a/src/bin/lttng-sessiond/ust-app.cpp
+++ b/src/bin/lttng-sessiond/ust-app.cpp
@@ -179,7 +179,7 @@ static void copy_channel_attr_to_ustctl(struct
lttng_ust_ctl_consumer_channel_at
static int ht_match_ust_app_event(struct cds_lfht_node *node, const void *_key)
{
struct ust_app_event *event;
- const struct ust_app_ht_key *key;
+ const struct ltt_ust_ht_key *key;
int ev_loglevel_value;
LTTNG_ASSERT(node);
@@ -253,7 +253,7 @@ no_match:
static void add_unique_ust_app_event(struct ust_app_channel *ua_chan, struct
ust_app_event *event)
{
struct cds_lfht_node *node_ptr;
- struct ust_app_ht_key key;
+ struct ltt_ust_ht_key key;
struct lttng_ht *ht;
LTTNG_ASSERT(ua_chan);
@@ -263,7 +263,8 @@ static void add_unique_ust_app_event(struct ust_app_channel
*ua_chan, struct ust
ht = ua_chan->events;
key.name = event->attr.name;
key.filter = event->filter;
- key.loglevel_type = (lttng_ust_abi_loglevel_type) event->attr.loglevel;
+ key.loglevel_type = event->attr.loglevel_type;
+ key.loglevel_value = event->attr.loglevel;
key.exclusion = event->exclusion;
node_ptr = cds_lfht_add_unique(ht->ht,
@@ -1499,13 +1500,14 @@ error:
static struct ust_app_event *find_ust_app_event(struct lttng_ht *ht,
const char *name,
const struct lttng_bytecode
*filter,
+ enum
lttng_ust_abi_loglevel_type loglevel_type,
int loglevel_value,
const struct
lttng_event_exclusion *exclusion)
{
struct lttng_ht_iter iter;
struct lttng_ht_node_str *node;
struct ust_app_event *event = nullptr;
- struct ust_app_ht_key key;
+ struct ltt_ust_ht_key key;
LTTNG_ASSERT(name);
LTTNG_ASSERT(ht);
@@ -1513,7 +1515,8 @@ static struct ust_app_event *find_ust_app_event(struct
lttng_ht *ht,
/* Setup key for event lookup. */
key.name = name;
key.filter = filter;
- key.loglevel_type = (lttng_ust_abi_loglevel_type) loglevel_value;
+ key.loglevel_type = loglevel_type;
+ key.loglevel_value = loglevel_value;
/* lttng_event_exclusion and lttng_ust_event_exclusion structures are
similar */
key.exclusion = exclusion;
@@ -5004,6 +5007,7 @@ int ust_app_disable_event_glb(struct ltt_ust_session
*usess,
ua_event = find_ust_app_event(ua_chan->events,
uevent->attr.name,
uevent->filter,
+
uevent->attr.loglevel_type,
uevent->attr.loglevel,
uevent->exclusion);
if (ua_event == nullptr) {
@@ -5167,6 +5171,7 @@ int ust_app_enable_event_glb(struct ltt_ust_session
*usess,
ua_event = find_ust_app_event(ua_chan->events,
uevent->attr.name,
uevent->filter,
+
uevent->attr.loglevel_type,
uevent->attr.loglevel,
uevent->exclusion);
if (ua_event == nullptr) {
@@ -5952,6 +5957,7 @@ static int ust_app_channel_synchronize_event(struct
ust_app_channel *ua_chan,
ua_event = find_ust_app_event(ua_chan->events,
uevent->attr.name,
uevent->filter,
+ uuevent->attr.loglevel_type,
uevent->attr.loglevel,
uevent->exclusion);
if (!ua_event) {
diff --git a/src/bin/lttng-sessiond/ust-app.hpp
b/src/bin/lttng-sessiond/ust-app.hpp
index fdc007853..7781984ff 100644
--- a/src/bin/lttng-sessiond/ust-app.hpp
+++ b/src/bin/lttng-sessiond/ust-app.hpp
@@ -41,13 +41,6 @@ struct ust_app_notify_sock_obj {
struct rcu_head head;
};
-struct ust_app_ht_key {
- const char *name;
- const struct lttng_bytecode
Re: [lttng-dev] I'm still getting empty ust traces using tracef
On Thu, May 11, 2023 at 12:36 PM Brian Hutchinson wrote: > > ... more background. I've always used ltt in the kernel so I don't > have much experience with the user side of it and especially > multi-threaded, multi-core so I'm probably missing some fundamental > concepts that I need to understand. > > Regards, > > Brian I'm currently reading up on the new v2.13 "Recording event rule and event record" features. I came to 2.13 because I want to be able to trigger snapshots on an event so I don't fill up storage on an embedded device. After I start lttng-systemd --daemonize and then start my app, I see this when I do lttng list --userspace: # lttng-sessiond --daemonize [ 85.180717] LTTng: Loaded modules v2.13.9 (Nordicit�é) [ 85.186103] LTTng: Experimental bitwise enum enabled. # lttng list --userspace UST events: - PID: 617 - Name: sh lttng_ust_libc:posix_memalign (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:memalign (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:realloc (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:calloc (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:free (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:malloc (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_pthread:pthread_mutex_unlock (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_pthread:pthread_mutex_trylock (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_pthread:pthread_mutex_lock_acq (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_pthread:pthread_mutex_lock_req (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_dl:dlclose (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_dl:debug_link (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_dl:build_id (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_dl:dlmopen (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_dl:dlopen (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG (loglevel: TRACE_DEBUG (14)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_LINE (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_FUNCTION (loglevel: TRACE_DEBUG_FUNCTION (12)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_UNIT (loglevel: TRACE_DEBUG_UNIT (11)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_MODULE (loglevel: TRACE_DEBUG_MODULE (10)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_PROCESS (loglevel: TRACE_DEBUG_PROCESS (9)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_PROGRAM (loglevel: TRACE_DEBUG_PROGRAM (8)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_SYSTEM (loglevel: TRACE_DEBUG_SYSTEM (7)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_INFO (loglevel: TRACE_INFO (6)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_NOTICE (loglevel: TRACE_NOTICE (5)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_WARNING (loglevel: TRACE_WARNING (4)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_ERR (loglevel: TRACE_ERR (3)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_CRIT (loglevel: TRACE_CRIT (2)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_ALERT (loglevel: TRACE_ALERT (1)) (type: tracepoint) lttng_ust_tracelog:LTTNG_UST_TRACEPOINT_LOGLEVEL_EMERG (loglevel: TRACE_EMERG (0)) (type: tracepoint) lttng_ust_tracef:event (loglevel: TRACE_DEBUG (14)) (type: tracepoint) lttng_ust_lib:unload (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_lib:debug_link (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_lib:build_id (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_lib:load (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:end (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:procname (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:debug_link (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:build_id (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:bin_info (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_statedump:start (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) PID: 601 - Name: /usr/loal/bin/my_app lttng_ust_libc:posix_memalign (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) lttng_ust_libc:memalign (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint)
Re: [lttng-dev] I'm still getting empty ust traces using tracef
On Thu, May 11, 2023 at 2:14 PM Michael Jeanson wrote: > > On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote: > > ... more background. I've always used ltt in the kernel so I don't > > have much experience with the user side of it and especially > > multi-threaded, multi-core so I'm probably missing some fundamental > > concepts that I need to understand. > > > > Regards, > > > > Brian > > Hi, > > If you are static linking 'liblttng-ust' then the library constructor won't be All of the final executable is a bunch of statically linked libs (all .a's) but lttng-ust isn't statically linked (using .so.1, not .a). I couldn't build/link without linking -llttng-ust and -ldl. > executed and you'll get no traces. While this setup is untested and > unsupported, you could call the UST constructor from your application early > initialisation but that would require patching lttng-ust to export the > 'lttng_ust_ctor' symbol. > > And the first thing to do to start diagnosing UST tracing issues is to run > your application with hte LTTNG_UST_DEBUG environment variable set, see [1] Thanks! I'll check that reference out. Regards, Brian > for details. > > Cheers, > > Michael > > [1] https://lttng.org/man/3/lttng-ust/v2.13/#doc-_environment_variables > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] I'm still getting empty ust traces using tracef
Hi Mathieu, On Thu, May 11, 2023 at 2:12 PM Mathieu Desnoyers wrote: > > On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote: > > ... more background. I've always used ltt in the kernel so I don't > > have much experience with the user side of it and especially > > multi-threaded, multi-core so I'm probably missing some fundamental > > concepts that I need to understand. > > Which are the exact versions of LTTng-UST and LTTng-Tools you are using > now ? (2.13.N or which git commit ?) > > Thanks, > > Mathieu Built into my rootfs with Yocto: -rw-r--r-- 4 hutch hutch 977252 May 2 15:32 lttng-tools-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 11466008 May 2 15:33 lttng-tools-dbg-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch49104 May 2 15:32 lttng-tools-dev-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch87452 May 2 15:32 lttng-tools-doc-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 1602356 May 2 15:32 lttng-tools-ptest-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 867164 May 2 15:32 lttng-tools-src-2.13.9-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 219952 May 2 15:31 lttng-ust-2.13.5-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 9248 May 2 15:31 lttng-ust-bin-2.13.5-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 970248 May 2 15:31 lttng-ust-dbg-2.13.5-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch49132 May 2 15:31 lttng-ust-dev-2.13.5-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch39864 May 2 15:31 lttng-ust-doc-2.13.5-r0.aarch64.rpm -rw-r--r-- 4 hutch hutch 258392 May 2 15:31 lttng-ust-src-2.13.5-r0.aarch64.rpm Regards, Brian > > > > > Regards, > > > > Brian > > > > On Thu, May 11, 2023 at 11:53 AM Brian Hutchinson > > wrote: > >> > >> Hi, > >> > >> I posted a while ago (thread - Using lttng 2.11 and UST doesn't appear > >> to work - getting empty trace files) about this problem I'm having > >> with getting empty trace logs. > >> > >> I've since upgraded to lttng v2.13 and while I can do a simple hello > >> world program with tracef and get events in the log files, my more > >> complicated large multi-threaded app I'm trying to debug is still > >> getting empty log file traces. > >> > >> I can list the user space events in my app. > >> > >> Next I do: > >> > >> lttng enable-event --userspace 'lttng_ust_tracef:*' > >> > >> ... to enable the events, start lttng, start my app, and I get a > >> trace directory structure that's empty. > >> > >> I feel like I've read every thread in the archives about people having > >> the same problem. > >> > >> I did try using LD_PRELOAD with various libs thinking that was the > >> problem but so far I'm still getting empty traces. > >> > >> So far I've tried: > >> > >> LD_PRELOAD=liblttng-ust-libc-wrapper.so.1:liblttng-ust-pthread-wrapper.so.1:liblttng-ust-dl.so.1:liblttng-ust-fork.so.1:liblttng-ust-fd.so.1 > >> /usr/local/bin/my_app > >> > >> I guess one question I have is how do I determine which "helper libs" > >> I need to preload? > >> > >> The application I'm working on is made up of a bunch of smaller static > >> libs linked together into one big executable and that is linked with > >> -llttng-ust and -ldl. > >> > >> I'm pretty stuck at the moment. Anyone have any wisdom on what I > >> might be doing wrong or how I can tell why I'm not getting events in > >> the logs? > >> > >> Thanks, > >> > >> Brian > > ___ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] I'm still getting empty ust traces using tracef
On 2023-05-11 14:13, Mathieu Desnoyers via lttng-dev wrote: On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote: ... more background. I've always used ltt in the kernel so I don't have much experience with the user side of it and especially multi-threaded, multi-core so I'm probably missing some fundamental concepts that I need to understand. Which are the exact versions of LTTng-UST and LTTng-Tools you are using now ? (2.13.N or which git commit ?) Also, can you try using lttng-ust stable-2.13 branch, which includes the following commit ? commit be2ca8b563bab81be15cbce7b9f52422369f79f7 Author: Mathieu Desnoyers Date: Tue Feb 21 14:29:49 2023 -0500 Fix: Reevaluate LTTNG_UST_TRACEPOINT_DEFINE each time tracepoint.h is included Fix issues with missing symbols in use-cases where tracef.h is included before defining LTTNG_UST_TRACEPOINT_DEFINE, e.g.: #include #define LTTNG_UST_TRACEPOINT_DEFINE #include It is caused by the fact that tracef.h includes tracepoint.h in a context which has LTTNG_UST_TRACEPOINT_DEFINE undefined, and this is not re-evaluated for the following includes. Fix this by lifting the definition code in tracepoint.h outside of the header include guards, and #undef the old LTTNG_UST__DEFINE_TRACEPOINT before re-defining it to its new semantic. Use a new _LTTNG_UST_TRACEPOINT_DEFINE_ONCE include guard within the LTTNG_UST_TRACEPOINT_DEFINE defined case to ensure symbols are not duplicated. Signed-off-by: Mathieu Desnoyers Change-Id: I0ef720435003a7ca0bfcf29d7bf27866c5ff8678 Thanks, Mathieu Thanks, Mathieu Regards, Brian On Thu, May 11, 2023 at 11:53 AM Brian Hutchinson wrote: Hi, I posted a while ago (thread - Using lttng 2.11 and UST doesn't appear to work - getting empty trace files) about this problem I'm having with getting empty trace logs. I've since upgraded to lttng v2.13 and while I can do a simple hello world program with tracef and get events in the log files, my more complicated large multi-threaded app I'm trying to debug is still getting empty log file traces. I can list the user space events in my app. Next I do: lttng enable-event --userspace 'lttng_ust_tracef:*' ... to enable the events, start lttng, start my app, and I get a trace directory structure that's empty. I feel like I've read every thread in the archives about people having the same problem. I did try using LD_PRELOAD with various libs thinking that was the problem but so far I'm still getting empty traces. So far I've tried: LD_PRELOAD=liblttng-ust-libc-wrapper.so.1:liblttng-ust-pthread-wrapper.so.1:liblttng-ust-dl.so.1:liblttng-ust-fork.so.1:liblttng-ust-fd.so.1 /usr/local/bin/my_app I guess one question I have is how do I determine which "helper libs" I need to preload? The application I'm working on is made up of a bunch of smaller static libs linked together into one big executable and that is linked with -llttng-ust and -ldl. I'm pretty stuck at the moment. Anyone have any wisdom on what I might be doing wrong or how I can tell why I'm not getting events in the logs? Thanks, Brian ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] I'm still getting empty ust traces using tracef
On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote: ... more background. I've always used ltt in the kernel so I don't have much experience with the user side of it and especially multi-threaded, multi-core so I'm probably missing some fundamental concepts that I need to understand. Regards, Brian Hi, If you are static linking 'liblttng-ust' then the library constructor won't be executed and you'll get no traces. While this setup is untested and unsupported, you could call the UST constructor from your application early initialisation but that would require patching lttng-ust to export the 'lttng_ust_ctor' symbol. And the first thing to do to start diagnosing UST tracing issues is to run your application with hte LTTNG_UST_DEBUG environment variable set, see [1] for details. Cheers, Michael [1] https://lttng.org/man/3/lttng-ust/v2.13/#doc-_environment_variables ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] I'm still getting empty ust traces using tracef
On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote: ... more background. I've always used ltt in the kernel so I don't have much experience with the user side of it and especially multi-threaded, multi-core so I'm probably missing some fundamental concepts that I need to understand. Which are the exact versions of LTTng-UST and LTTng-Tools you are using now ? (2.13.N or which git commit ?) Thanks, Mathieu Regards, Brian On Thu, May 11, 2023 at 11:53 AM Brian Hutchinson wrote: Hi, I posted a while ago (thread - Using lttng 2.11 and UST doesn't appear to work - getting empty trace files) about this problem I'm having with getting empty trace logs. I've since upgraded to lttng v2.13 and while I can do a simple hello world program with tracef and get events in the log files, my more complicated large multi-threaded app I'm trying to debug is still getting empty log file traces. I can list the user space events in my app. Next I do: lttng enable-event --userspace 'lttng_ust_tracef:*' ... to enable the events, start lttng, start my app, and I get a trace directory structure that's empty. I feel like I've read every thread in the archives about people having the same problem. I did try using LD_PRELOAD with various libs thinking that was the problem but so far I'm still getting empty traces. So far I've tried: LD_PRELOAD=liblttng-ust-libc-wrapper.so.1:liblttng-ust-pthread-wrapper.so.1:liblttng-ust-dl.so.1:liblttng-ust-fork.so.1:liblttng-ust-fd.so.1 /usr/local/bin/my_app I guess one question I have is how do I determine which "helper libs" I need to preload? The application I'm working on is made up of a bunch of smaller static libs linked together into one big executable and that is linked with -llttng-ust and -ldl. I'm pretty stuck at the moment. Anyone have any wisdom on what I might be doing wrong or how I can tell why I'm not getting events in the logs? Thanks, Brian ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] I'm still getting empty ust traces using tracef
... more background. I've always used ltt in the kernel so I don't have much experience with the user side of it and especially multi-threaded, multi-core so I'm probably missing some fundamental concepts that I need to understand. Regards, Brian On Thu, May 11, 2023 at 11:53 AM Brian Hutchinson wrote: > > Hi, > > I posted a while ago (thread - Using lttng 2.11 and UST doesn't appear > to work - getting empty trace files) about this problem I'm having > with getting empty trace logs. > > I've since upgraded to lttng v2.13 and while I can do a simple hello > world program with tracef and get events in the log files, my more > complicated large multi-threaded app I'm trying to debug is still > getting empty log file traces. > > I can list the user space events in my app. > > Next I do: > > lttng enable-event --userspace 'lttng_ust_tracef:*' > > ... to enable the events, start lttng, start my app, and I get a > trace directory structure that's empty. > > I feel like I've read every thread in the archives about people having > the same problem. > > I did try using LD_PRELOAD with various libs thinking that was the > problem but so far I'm still getting empty traces. > > So far I've tried: > > LD_PRELOAD=liblttng-ust-libc-wrapper.so.1:liblttng-ust-pthread-wrapper.so.1:liblttng-ust-dl.so.1:liblttng-ust-fork.so.1:liblttng-ust-fd.so.1 > /usr/local/bin/my_app > > I guess one question I have is how do I determine which "helper libs" > I need to preload? > > The application I'm working on is made up of a bunch of smaller static > libs linked together into one big executable and that is linked with > -llttng-ust and -ldl. > > I'm pretty stuck at the moment. Anyone have any wisdom on what I > might be doing wrong or how I can tell why I'm not getting events in > the logs? > > Thanks, > > Brian ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] I'm still getting empty ust traces using tracef
Hi, I posted a while ago (thread - Using lttng 2.11 and UST doesn't appear to work - getting empty trace files) about this problem I'm having with getting empty trace logs. I've since upgraded to lttng v2.13 and while I can do a simple hello world program with tracef and get events in the log files, my more complicated large multi-threaded app I'm trying to debug is still getting empty log file traces. I can list the user space events in my app. Next I do: lttng enable-event --userspace 'lttng_ust_tracef:*' ... to enable the events, start lttng, start my app, and I get a trace directory structure that's empty. I feel like I've read every thread in the archives about people having the same problem. I did try using LD_PRELOAD with various libs thinking that was the problem but so far I'm still getting empty traces. So far I've tried: LD_PRELOAD=liblttng-ust-libc-wrapper.so.1:liblttng-ust-pthread-wrapper.so.1:liblttng-ust-dl.so.1:liblttng-ust-fork.so.1:liblttng-ust-fd.so.1 /usr/local/bin/my_app I guess one question I have is how do I determine which "helper libs" I need to preload? The application I'm working on is made up of a bunch of smaller static libs linked together into one big executable and that is linked with -llttng-ust and -ldl. I'm pretty stuck at the moment. Anyone have any wisdom on what I might be doing wrong or how I can tell why I'm not getting events in the logs? Thanks, Brian ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [RFC] Deprecating RCU signal flavor
Hi Olivier, we (DeepBlueCapital) gave up on urcu-signal a long time ago, due to the annoying side effects signals can have. Nowadays we use membarrier, so removing urcu-signal is fine as far as we are concerned. Best wishes, Duncan. On 10/05/2023 23:10, Olivier Dion via lttng-dev wrote: Hi all, We have the intention of deprecating the urcu-signal flavor in the future. We are asking users of URCU for _feedback_ on this before going any further. Part of this decision is that we are adding support for TSAN in URCU and the signal flavor deadlocks with TSAN. It is also my understanding that the urcu-signal flavor was historically made as a fallback for system lacking the membarrier(2) system call. Nowadays, most systems have support for that system call, making the urcu-signal an artifact of the past. The following is a proposed timeline of events: 1. Asking for feedback from users of URCU (this message) 2. Disabling the signal flavor by default and adding --enable-flavor-signal 3. Removing the signal flavor ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
