Hi Brian,
On 7/12/24 2:56 PM, Brian Hutchinson wrote:
Hi again Kienan,
Manifest says librcu is 0.13.2.
thanks
The app is made up of a bunch of sup projects (about 40 or so) that are
built into a bunch of .o objects (I think it's a structure automatically
setup by cmake) and finally linked together with the main app .o object
so it looks like it's all static linking.
The part where I put in a call to lttng-ust trace is in one of the sub
projects. Looking at all of your example linking scenarios in the
documentation, I think what we are doing fits the same scenario as the
hello world build/link.
All of the sub project .o's are linked with the main app's .o and linked
with lttng-ust and ld at the end.
I've also tried building the trace provider bits linked with lttng-ust
and dl as a .so and using LD_PRELOAD to load that before starting the
app. I get same segfault that way too.
Stupid question. Do I need to create a lttng session or something
before the app with lttng-ust tracepoints even runs? Reason I ask is,
systemd starts up several other apps that setup and do things that the
app in question needs before it can run so I was hoping the app could
start then I create a session and attach to the pid to do tracing. I
can't really start it like the hello world where is runs and pauses
while you wait for a key press and then setup and start all the lttng
session and recording bits, then hit a key and the tracepoints are
exercised. From all I've read, an application with lttng-ust
tracepoints should run as a normal program and the tracing lines do
nothing until a lttng session is started and the tracepoints enabled.
It's not necessary to create a session, or even have the sessiond
running when a traced application is launched.
When an application that is compiled with user-space tracing, there's
are early constructors that run prior to the application's main entry
point. By default this waits for up to 3000ms to perform registration
with a sessiond before continuing to the program's main entry point.
This delay is controlled by the environment variable
LTTNG_UST_REGISTER_TIMEOUT ( see
https://lttng.org/man/3/lttng-ust/v2.13/#doc-_environment_variables ).
The UST application also opens a piece of shared memory at a well known
location and reads it waiting for changes. The sessiond will write to
the shared memory at the location when it starts to signal to any UST
apps that registration can be retried. C.f.
https://github.com/lttng/lttng-ust/blob/9b9714603cfa96a63a42dc9cb8266f81df42a4f3/src/lib/lttng-ust/lttng-ust-comm.c#L1978
Thought I'd ask in case my understanding is wrong and how I'm starting
things up is the problem.
I'll work on fixing the 2.13.8 lttng-ust built (as I'm not convinced yet
it's right based on what I mentioned before) and let you know how it goes.
If you're not sure re: size, you could always compute a sha512 sum for
the libraries.
thanks,
kienan
P.S. Could you please keep lttng-dev in CC? thank you.
Thanks and have a good weekend!
Regards,
Brian
On Fri, Jul 12, 2024 at 10:30 AM Brian Hutchinson <b.hutch...@gmail.com
<mailto:b.hutch...@gmail.com>> wrote:
No, it's a giant app. But made what I'm trying to test as simple
as possible to demonstrate the error ... its the same trace provider
that worked with hello world and my app is just calling a line of that.
I don't think I did something right with my 2.13.8 build. Bitbake
made a package that says it's 2.13.8 but I compared the files to
2.13.6 and the file sizes were all identical so somethings not
right. So I need to figure out why recipe isn't working.
I'm off work today but when I get a chance I'll check manifest and
get you the rcu version and try to describe how app is built.
Thanks,
Brian
On Fri, Jul 12, 2024, 10:17 AM Kienan Stewart <kstew...@efficios.com
<mailto:kstew...@efficios.com>> wrote:
Hi Brian,
On 7/11/24 7:20 PM, Brian Hutchinson wrote:
> Hi Kienan
>
> Do I need to update lttng-tools and modules too? I did a
bbappend and
> pulled in 2.13.8 recipe from master and get the same issue.
I'm double
> checking to make sure everything built right. Had to update
sdk, rootfs
> and rebuild app with new sdk etc.
I don't believe so.
Do you have a minimal reproducer example that you are able to share
including the build instructions you are using?
Also, which version of urcu is being used in your environment?
thanks,
kienan
>
> Regards,
>
> Brian
>
> On Thu, Jul 11, 2024 at 8:38 AM Kienan Stewart
<kstew...@efficios.com <mailto:kstew...@efficios.com>
> <mailto:kstew...@efficios.com
<mailto:kstew...@efficios.com>>> wrote:
>
> Hi Brian,
>
> On 7/11/24 8:33 AM, Brian Hutchinson via lttng-dev wrote:
> > ...
> >
> > I'm not sure about this, still trying to comprehend
everything,
> but I
> > think my issue could be related to all this gcc TLS,
heap,
> trampoline
> > talk here:
> >
> >
>
https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html
<https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html>
>
<https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html <https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html>>
> >
>
<https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html <https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html> <https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html <https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html>>>
> >
> > Regards,
> >
> > Brian
> >
>
> You could try using lttng-ust 2.13.8, which includes a
fix for the
> discussion you referenced.
>
>
https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd26c25965e836
<https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd26c25965e836>
<https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd26c25965e836
<https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd26c25965e836>>
>
> Please let us know if it doesn't solve it.
>
> thanks,
> kienan
>
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
