Re: [lttng-dev] What is DEFINE_LTTNG_UST_SIGBUS_STATE for and other beginner questions

On Wed, Oct 4, 2023, at 3:04 PM, Kienan Stewart wrote:
> Hi Chris,
>
> On 2023-10-04 12:56, Christopher Harvey via lttng-dev wrote:
>> Hi all,
>> 
>> I'm just getting started with lttng and have a couple of questions. My target is getting userspace tracepoints to work in a c++ application I control. I don't need kernel or system tracing. The target is running in a docker container I have control over as well. Running with --privileged is possible in my setup. I could run lttng inside the target container, outside on the host, or in another container on the same host. It's all the same to me. I don't know which setup is best, or if it even matters given that I don't need system or kernel traces.
>> 
>> I am using:
>> lttng-tools-2.13.11/      and       lttng-ust-2.13.6/
>> with userspace-rcu-0.14.0/
>> 
>> There is a slight version mismatch there, I just downloaded the "-lastest" from the links in the guide.
>> 
>> Here is my tracepoint provider header:
>> -----
[SNIP]
>> --------
>> 
>> and the cpp:
>> -------
[SNIP]
>> ----
>> 
>> I'm suspicious of a couple of things in my setup.
>> 
>> First, if I omit the DEFINE_LTTNG_UST_SIGBUS_STATE(); line, my program fails to compile with the following error:
>> liblttng-ust-ctl.so: undefined reference to `lttng_ust_sigbus_state'
>> 
>
> I wasn't able to reproduce the compilation error you are seeing. Could 
> you describe in more detail how you are compiling and linking your 
> tracepoint provider and application?

I just create a .o from the tracepoint provider compilation unit. I'm not making shared libraries or anything like that. More on this below.

>> The getting started guide doesn't say anything about needing DEFINE_LTTNG_UST_SIGBUS_STATE so it makes me wonder if I have done something else wrong somewhere else. I ran a find *.so | xargs nm -D | grep lttng_ust_sigbus_state and nothing in lttng-ust provides that symbol, so it looks like the target application has to define it. Is that normal?
>> 
>
> If the application is actually using liblttng-ust-ctl, then it would be 
> normal to do the define. The header file explains that this is done to 
> avoid unnecessarily pre-allocating space in the thread-local storage.
> https://github.com/lttng/lttng-ust/blob/master/include/lttng/ust-sigbus.h#L39
>
> Traced applications typically don't link against liblttng-ust-ctl.
>

This ended up being one of the main problems. My final linking flags are
-llttng-ust -llttng-ust-common -llttng-ust-tracepoint
I didn't have a particular reason for linking against liblttng-ust-ctl before. It was a mistake.

>> If I leave DEFINE_LTTNG_UST_SIGBUS_STATE in then my program compiles. If I run lttng-sessiond in the target container, then run lttng list --userspace I see no tracepoints in the list.
>> 
>
> Is your application actively running while you run `lttng list --userspace`?

yes

I was reading some lttng-sessiond source code and discovered -vvv as well as LTTNG_UST_DEBUG.

I'm still not seeing the tracepoints show up in lttng list --userspace, but I found more hints as to why.
Here is some output from my target application:
 liblttng_ust[454/467]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:1884)
liblttng_ust[454/467]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:1758

These prints only happen periodically when lttng-sessiond is running. If I stop lttng-sessiond then the prints stop so there is clearly some communication happening. Apparently this gets printed when there is an ECONNREFUSED from lttng-sessiond. I haven't gotten much further than that right now. I have pasted the output from sessiond -vvv here:

https://pastebin.com/raw/ayJJ2J9p

thank you for your time,
Chris
_______________________________________________
lttng-dev mailing list
[email protected]
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev