Re: [lttng-dev] Using lttng-ust 2.13.6 from Yocto Kirkstone and getting weird segfault saying strlen_asimd.S can't be found.

[Kienan Stewart via lttng-dev <lttng-dev@lists.lttng.org>]

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.hutchman@gmail.com 
> <mailto:b.hutchman@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 <kstewart@efficios.com
>     <mailto:kstewart@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
>         <kstewart@efficios.com <mailto:kstewart@efficios.com>
>          > <mailto:kstewart@efficios.com
>         <mailto:kstewart@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