From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xsbEAgjxl2YhzikAWB0awg (envelope-from ) for ; Wed, 17 Jul 2024 12:27:52 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=VOevKXKA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EE9631E0C3; Wed, 17 Jul 2024 12:27:51 -0400 (EDT) Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DB7B51E097 for ; Wed, 17 Jul 2024 12:27:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1721233669; bh=eWsdpmKE6yGeVLdxl4o2Y+UAf+kQ0uaFZ7WFbstHjjQ=; h=References:In-Reply-To:Date:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=VOevKXKADvnLNLIqfkk62N/QYhKCfPvT+3cs6W0oxubwRJouWfvURt18QS8ulmC4C 1QQ8LGhVh2G77hCg0oobzMxl2Fa3luiktysoEjjNyr0OpWJ8YzxofaHHI8ea2mX59F 7NN30XrMFfxOkrBCPWo/8WU8jAJ9EvwNlMeKazbpLBEV7TCoiUC/uGvVm6ivXPHOiJ OFPbkIkyK5FyCGn7TI7vt81fRzPLpO2DUOuVZOad+Zq3EwIuuvG7C46vkS0a8rrPyT PsEt6VcMoRmjnNL541lHhBMocxx0lpfGo3EqHJ3A1IQzChumvvFrdW8e5BlxzVHXn6 siWaypMRRI1Lw== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4WPLvS6xssz12LZ; Wed, 17 Jul 2024 12:27:48 -0400 (EDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lists.lttng.org (Postfix) with ESMTPS id 4WPLvS2VYSz12QG for ; Wed, 17 Jul 2024 12:27:48 -0400 (EDT) Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-70b1808dee9so4791586b3a.2 for ; Wed, 17 Jul 2024 09:27:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721233667; x=1721838467; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0s4sW351UOPO15pV5RatoSfGBqOCIp0ZGc0ktkI/WBY=; b=BG2FrR7qXYbe1JECuGELqs3l+OhdjrGvNhABh/kb/QgzPCTbFtbvZ+yrhQnz8+u5eb HwtM6X+1IiqPdzSRfhple1rT65Vt+M5bCdVjCgaA/QEKi7OiqzumqnBc5ClvHaUyqzBv NrFnjYDYawAFXPTv8y0WTx3hpa2iId6hb6IIpf4PwDb4CMAyDrQmXXUMgssF2eHQGrEf aWV5hTe9PZBtQWND+AZZcUGgrOO4rWM3Ia+UtPNumAIherTwwcdrit/e5HYhmqSfgSZ4 t/NQEn3TK+zRRckbWFkBAjK7jAwdOm6YTwvjdmRRBmfWlSIWcoN7vgmkiAtedkq//isc lsuw== X-Gm-Message-State: AOJu0Ywa4txVC9jqu2jC+R5pgc4dnMoYhpy6PK4NZ6GA8myG9ZPe6r4b RTVDzILpXo4VDRl0wy1QTVXPbBX/UYKzq9KsVbKthm6WDuMcqDSu7jYG4fI2Z9Gh1CB402d6+yb vN9NlrXPw59jLgfFygRAoFMFfiQs= X-Google-Smtp-Source: AGHT+IHVUXsm8v4Et5ZUaohFmSMxDnkQdqIZ5ztJ6a8RtVrlRf8XyuTYaXrY+NMIXwqrljYTFOLssYuk3lVrMtQLwB4= X-Received: by 2002:a05:6a20:2d06:b0:1c0:e4d6:9c05 with SMTP id adf61e73a8af0-1c3fdd0fa8emr2145003637.32.1721233666809; Wed, 17 Jul 2024 09:27:46 -0700 (PDT) MIME-Version: 1.0 References: <33527830-3bf3-4bc3-a53d-55eaefb74902@efficios.com> In-Reply-To: <33527830-3bf3-4bc3-a53d-55eaefb74902@efficios.com> Date: Wed, 17 Jul 2024 12:27:35 -0400 Message-ID: To: Kienan Stewart Cc: lttng-dev@lists.lttng.org, yocto@lists.yoctoproject.org Subject: Re: [lttng-dev] Using lttng-ust 2.13.6 from Yocto Kirkstone and getting weird segfault saying strlen_asimd.S can't be found. X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Brian Hutchinson via lttng-dev Reply-To: Brian Hutchinson Content-Type: multipart/mixed; boundary="===============1071897157144700149==" Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --===============1071897157144700149== Content-Type: multipart/alternative; boundary="000000000000492929061d73f16f" --000000000000492929061d73f16f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2024 at 10:13=E2=80=AFAM Kienan Stewart wrote: > Hi Brian, > > thanks! I'll take a look at these and see if I can get any ideas from the= m. > > To go back to your original e-mail, a detail that I hadn't noticed in > your original backtrace was pointed out to me and I'd like to verify > with you: > > ``` > Core was generated by `./my_app'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:96 > 96 ../sysdeps/aarch64/multiarch/strlen_asimd.S: No such file or > directory. > [Current thread is 1 (Thread 0xffffb8e2d040 (LWP 757))] > (gdb) bt > #0 __strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:96 > #1 0x0000ffffb86c5330 in lttng_ust_tracepoint_module_register () from > /usr/lib/liblttng-ust-tracepoint.so.1 > #2 0x0000aaaab4c8da18 in lttng_ust__tracepoints__ptrs_init () at > > /opt/poky/4.0.18/sysroots/cortexa53-crypto-poky-linux/usr/include/lttng/t= racepoint.h:629 > #3 0x0000ffffb872b30c in call_init (env=3D, > argv=3D0xffffe2d66098, argc=3D1) at ../csu/libc-start.c:145 > #4 __libc_start_main_impl (main=3D0xaaaab4bd94e0
, argc=3D1, > argv=3D0xffffe2d66098, init=3D, fini=3D, > rtld_fini=3D, stack_end=3D) at > ../csu/libc-start.c:376 > #5 0x0000aaaab4bd9230 in _start () at ../sysdeps/aarch64/start.S:81 > ``` > > The library loaded at frame 1 is > `/usr/lib/liblttng-ust-tracepoint.so.1`; however, in frame 2 the > reference is from > > `/opt/poky/4.0.18/sysroots/cortexa53-crypto-poky-linux/usr/include/lttng/= tracepoint.h`. > Are the LTTng libraries in `/usr/lib` the exact same version as the > headers in > `/opt/poky/4.0.18/sysroots/cortexa53-cryptop-poky-linux/usr/include/lttng= `? > Yes. The sdk was created by yocto using populate_sdk which includes the target image sysroot in the sdk. Hopefully I explained that right. The target image drives the contents of the sdk and the generated sdk is what is used to cross compile the application specifically for the target we are running on (NXP imx8mm). > If some of your app is compiled using one version of headers and a > different version of the library is loaded at runtime, there could be an > ABI mismatch. > > You could check what the include paths are during compilation and > `LD_LIBRARY_PATH` at runtime. Running with the environment variable > `LD_DEBUG=3Dbindings,libs` (see `man ld.so` for more info). > I've been down that road a few times before with the same line of thinking (ABI issue) and believe I've proven I don't have those issues. That's one of the reasons I hand built lttng-ust in native environment (on the actual target) to verify it wasn't an issue with a yocto recipe, cross compiling etc.. I've been thru this process with different OS versions (yocto Dunfell before), kernel version, toolchain version etc., and now the same with Kirkstone based components. > In any case, I'll take a look over the most recent backtraces and see if > anything else jumps out. > Thanks! I'm running out of things to try. I don't fully understand the implications of some of this documentation, but I have learned enough to know LD_PRELOAD means nothing if everything is static built. Our application is heavily multi threaded, uses fork, clone and who knows if it's doing double closes or not ... so I've tried these LD_PRELOAD "helpers" or whatever they are, before and didn't get a different result, but now know it's only for shared library object. So now I will experiment with making our tpp a shared object and try LD_PRELOAD of fork, fd and pthread helpers and starting my app that way. This is what I'm referring to above from the lttng docs: Use LTTng-UST with daemons If your instrumented application calls fork(2) , clone(2) , or BSD=E2=80=99s rfor= k(2) , without a following exec(3) -family system call, you must preload the liblttng-ust-fork.so shared object when you start the application. LD_PRELOAD=3Dliblttng-ust-fork.so ./my-app If your tracepoint provider package is a shared library which you also preload, you must put both shared objects in LD_PRELOAD: LD_PRELOAD=3Dliblttng-ust-fork.so:/path/to/tp.so ./my-app Use LTTng-UST with applications which close file descriptors that don=E2=80= =99t belong to them Since 2.9 If your instrumented application closes one or more file descriptors which it did not open itself, you must preload the liblttng-ust-fd.so shared object when you start the application: LD_PRELOAD=3Dliblttng-ust-fd.so ./my-app Typical use cases include closing all the file descriptors after fork(2) or rfork(2) and buggy applications doing =E2=80=9Cdouble closes=E2=80=9D. Thanks, Brian > > > On 7/16/24 9:27 PM, Brian Hutchinson wrote: > > Hi Kienan, > > > > On Thu, Jul 11, 2024 at 8:38=E2=80=AFAM Kienan Stewart > > 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.htm= l > > < > 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/5db715e800d9b721f48495a987cd26c= 25965e836 > < > https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd26c= 25965e836 > > > > > > Please let us know if it doesn't solve it. > > > > thanks, > > kienan > > > > > > I updated to lttng-ust 2.13.8 as you suggested. At first, I pulled in > > the recipe from master branch of Yocto, but had the same problem as > > before after rebuilding. > > > > Next, I downloaded the 2.13.8 lttng-ust tarball from the lttng site and > > setup a native build environment on my target and built lttng-ust 2.13.= 8 > > and my app as a second independent build method for sanity check. I ca= n > > report that I get the exact same result as before this way too. > > > > In both cases, I verified that I had the commit you referenced above. > > > > I did a backtrace of the three threads captured in the coredump and sho= w > > them below in hopes it will shed light on what I need to try next. > > > > (gdb) thread apply all backtrace > > > > Thread 3 (Thread 0xffffbe7de7e0 (LWP 559)): > > #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38 > > #1 0x0000ffffbeef1bb8 in lttng_ust_futex (val3=3D0, uaddr2=3D0x0, > > timeout=3D0x0, val=3D0, op=3D0, uaddr=3D0xffffbefd8000) at > > ../../../src/lib/lttng-ust/futex.h:56 > > #2 lttng_ust_futex_async (op=3D0, val=3D0, timeout=3D0x0, uaddr2=3D0x0= , val3=3D0, > > uaddr=3D0xffffbefd8000) at ../../../src/lib/lttng-ust/futex.h:88 > > #3 wait_for_sessiond (sock_info=3D0xffffbef6b638 ) at > > lttng-ust-comm.c:1761 > > #4 ust_listener_thread (arg=3D0xffffbef6b638 ) at > > lttng-ust-comm.c:1832 > > #5 0x0000ffffbe9206a8 in start_thread (arg=3D0xffffc1bd8687) at > > pthread_create.c:442 > > #6 0x0000ffffbe98801c in thread_start () at > > ../sysdeps/unix/sysv/linux/aarch64/clone.S:79 > > > > Thread 2 (Thread 0xffffbdfce7e0 (LWP 560)): > > #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38 > > #1 0x0000ffffbeef1bb8 in lttng_ust_futex (val3=3D0, uaddr2=3D0x0, > > timeout=3D0x0, val=3D0, op=3D0, uaddr=3D0xffffbefd7000) at > > ../../../src/lib/lttng-ust/futex.h:56 > > #2 lttng_ust_futex_async (op=3D0, val=3D0, timeout=3D0x0, uaddr2=3D0x0= , val3=3D0, > > uaddr=3D0xffffbefd7000) at ../../../src/lib/lttng-ust/futex.h:88 > > #3 wait_for_sessiond (sock_info=3D0xffffbef695e0 ) at > > lttng-ust-comm.c:1761 > > #4 ust_listener_thread (arg=3D0xffffbef695e0 ) at > > lttng-ust-comm.c:1832 > > #5 0x0000ffffbe9206a8 in start_thread (arg=3D0xffffc1bd8687) at > > pthread_create.c:442 > > #6 0x0000ffffbe98801c in thread_start () at > > ../sysdeps/unix/sysv/linux/aarch64/clone.S:79 > > > > Thread 1 (Thread 0xffffbefcf460 (LWP 545)): > > #0 __strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:96 > > #1 0x0000ffffbe834bd0 in lttng_ust_tp_validate_event_name > > (tp=3D0xaaaab8f14de0 > > , > > tp=3D0xaaaab8f14de0 > > ) at > > tracepoint.c:143 > > #2 add_callsite (tp=3D0xaaaab8f14de0 > > , > > lib=3D0xaaaae74fad30) at tracepoint.c:412 > > #3 lib_register_callsites (lib=3D0xaaaae74fad30) at tracepoint.c:552 > > #4 lttng_ust_tracepoint_module_register (tracepoints_start=3D > out>, tracepoints_count=3D) at tracepoint.c:956 > > #5 0x0000aaaab8758204 in lttng_ust.tracepoints.ptrs_init () > > #6 0x0000ffffbe8cb30c in call_init (env=3D, > > argv=3D0xffffc1bd8c88, argc=3D1) at ../csu/libc-start.c:145 > > #7 __libc_start_main_impl (main=3D0xaaaab867aabc
, argc=3D1, > > argv=3D0xffffc1bd8c88, init=3D, fini=3D, > > rtld_fini=3D, stack_end=3D) at > > ../csu/libc-start.c:376 > > #8 0x0000aaaab867a7f0 in _start () at ../sysdeps/aarch64/start.S:81 > > > > Regards, > > > > Brian > --000000000000492929061d73f16f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 17, 2024 at 10:13=E2=80= =AFAM Kienan Stewart <kstewart@efficios.com> wrote:
Hi Brian,

thanks! I'll take a look at these and see if I can get any ideas from t= hem.

To go back to your original e-mail, a detail that I hadn't noticed in <= br> your original backtrace was pointed out to me and I'd like to verify with you:

```
Core was generated by `./my_app'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0=C2=A0 __strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:9= 6
96=C2=A0 =C2=A0 =C2=A0 ../sysdeps/aarch64/multiarch/strlen_asimd.S: No such= file or
directory.
[Current thread is 1 (Thread 0xffffb8e2d040 (LWP 757))]
(gdb) bt
#0=C2=A0 __strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:9= 6
#1=C2=A0 0x0000ffffb86c5330 in lttng_ust_tracepoint_module_register () from=
/usr/lib/liblttng-ust-tracepoint.so.1
#2=C2=A0 0x0000aaaab4c8da18 in lttng_ust__tracepoints__ptrs_init () at
/opt/poky/4.0.18/sysroots/cortexa53-crypto-poky-linux/usr/include/lttng/tra= cepoint.h:629
#3=C2=A0 0x0000ffffb872b30c in call_init (env=3D<optimized out>,
argv=3D0xffffe2d66098, argc=3D1) at ../csu/libc-start.c:145
#4=C2=A0 __libc_start_main_impl (main=3D0xaaaab4bd94e0 <main>, argc= =3D1,
argv=3D0xffffe2d66098, init=3D<optimized out>, fini=3D<optimized o= ut>,
rtld_fini=3D<optimized out>, stack_end=3D<optimized out>) at ../csu/libc-start.c:376
#5=C2=A0 0x0000aaaab4bd9230 in _start () at ../sysdeps/aarch64/start.S:81 ```

The library loaded at frame 1 is
`/usr/lib/liblttng-ust-tracepoint.so.1`; however, in frame 2 the
reference is from
`/opt/poky/4.0.18/sysroots/cortexa53-crypto-poky-linux/usr/include/lttng/tr= acepoint.h`.

Are the LTTng libraries in `/usr/lib` the exact same version as the
headers in
`/opt/poky/4.0.18/sysroots/cortexa53-cryptop-poky-linux/usr/include/lttng`?=

Yes.=C2=A0 The sdk was created by yoct= o using populate_sdk which includes the target image sysroot in the sdk.=C2=A0 Hopefully I explained that right. T= he target image drives the contents of the sdk and the generated sdk is wha= t is used to cross compile the application specifically for the target we a= re running on (NXP imx8mm).


If some of your app is compiled using one version of headers and a
different version of the library is loaded at runtime, there could be an ABI mismatch.

You could check what the include paths are during compilation and
`LD_LIBRARY_PATH` at runtime. Running with the environment variable
`LD_DEBUG=3Dbindings,libs` (see `man ld.so` for more info).
=C2=A0
I've been down that road a few times before with= the same line of thinking (ABI issue) and believe I've proven I don= 9;t have those issues.=C2=A0 That's one of the reasons I hand built ltt= ng-ust in native environment (on the actual target) to verify it wasn't= an issue with a yocto recipe, cross compiling etc..

I've been thru this process with different OS versions (yocto Du= nfell before), kernel version, toolchain version etc., and now the same wit= h Kirkstone based components.
=C2=A0
In any case, I'll take a look over the most recent backtraces and see i= f
anything else jumps out.

Thanks!=C2=A0 = I'm running out of things to try.

I= don't fully understand the implications of some of this documentation,= but I have learned enough to know LD_PRELOAD means nothing if everything i= s static built.=C2=A0 Our application is heavily multi threaded, uses fork,= clone and who knows if it's doing double closes or not ... so I've= tried these LD_PRELOAD "helpers" or whatever they are, before an= d didn't get a different result, but now know it's only for shared = library object.=C2=A0 So now I will experiment with making our tpp a shared= object and try LD_PRELOAD of fork, fd and pthread helpers and starting my = app that way.

This is what I'm referring to ab= ove from the lttng docs:
Use LTTn= g-UST with daemons

If your instrumented application calls= fork(2), clone(2), or BSD=E2=80=99s rfo= rk(2), without a following exec(3)-f= amily system call, you must preload the liblttng-ust-fork.so shared object when you start the application.

LD_PRELOAD=
=3Dliblttng-ust-fork.so ./my-app

If your tracepoint provider = package is a shared library which you also preload, you must put both shared objects in LD_PRELOAD:

LD_PRELO=
AD=3Dliblttng-ust-fork.so:/path/to/tp.so ./my-app
Use <= span>LTTng-UST with applications which close file descriptors that d= on=E2=80=99t belong to them
Since 2.9

If your instrume= nted application closes one or more file descriptors which it did not open itself, you must preload the liblttng-ust-fd.so shared object when you start the applicatio= n:

LD_PRELOAD=3Dliblttng-ust-fd.so ./my-app

Typical use cases include closing all the file descriptors after fork(2) or rfork(2) and buggy applications doing =E2=80=9Cdouble closes=E2=80=9D.


Thanks,

=

Brian

=C2=A0


On 7/16/24 9:27 PM, Brian Hutchinson wrote:
> Hi Kienan,
>
> On Thu, Jul 11, 2024 at 8:38=E2=80=AFAM Kienan Stewart <kstewart@efficios.com <= br> > <mailto:= kstewart@efficios.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Brian,
>
>=C2=A0 =C2=A0 =C2=A0On 7/11/24 8:33 AM, Brian Hutchinson via lttng-dev = wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> I'm not sure about this, still tryi= ng to comprehend everything,
>=C2=A0 =C2=A0 =C2=A0but I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> think my issue could be related to all = this gcc TLS, heap,
>=C2=A0 =C2=A0 =C2=A0trampoline
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> talk here:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0https://= www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html
>=C2=A0 =C2=A0 =C2=A0<http= s://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0<http= s://www.mail-archive.com/lttng-dev@lists.lttng.org/msg13584.html <https://www.mail-archive.com/lttng= -dev@lists.lttng.org/msg13584.html>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Brian
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0You could try using lttng-ust 2.13.8, which include= s a fix for the
>=C2=A0 =C2=A0 =C2=A0discussion you referenced.
>
>=C2=A0 =C2=A0 =C2=A0https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987c= d26c25965e836 <https://github.com/lttng/lttng-ust/commit/5db715e800d9b721f48495a987cd2= 6c25965e836>
>
>=C2=A0 =C2=A0 =C2=A0Please let us know if it doesn't solve it.
>
>=C2=A0 =C2=A0 =C2=A0thanks,
>=C2=A0 =C2=A0 =C2=A0kienan
>
>
> I updated to lttng-ust 2.13.8 as you suggested.=C2=A0 At first, I pull= ed in
> the recipe from master branch of Yocto, but had the same problem as > before after rebuilding.
>
> Next, I downloaded the 2.13.8 lttng-ust tarball from the lttng site an= d
> setup a native build environment on my target and built lttng-ust 2.13= .8
> and my app as a second independent build method for sanity check.=C2= =A0 I can
> report that I get the exact same result as before this way too.
>
> In both cases, I verified that I had the commit you referenced above.<= br> >
> I did a backtrace of the three threads captured in the coredump and sh= ow
> them below in hopes it will shed light on what I need to try next.
>
> (gdb) thread apply all backtrace
>
> Thread 3 (Thread 0xffffbe7de7e0 (LWP 559)):
> #0 =C2=A0syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38=
> #1 =C2=A00x0000ffffbeef1bb8 in lttng_ust_futex (val3=3D0, uaddr2=3D0x0= ,
> timeout=3D0x0, val=3D0, op=3D0, uaddr=3D0xffffbefd8000) at
> ../../../src/lib/lttng-ust/futex.h:56
> #2 =C2=A0lttng_ust_futex_async (op=3D0, val=3D0, timeout=3D0x0, uaddr2= =3D0x0, val3=3D0,
> uaddr=3D0xffffbefd8000) at ../../../src/lib/lttng-ust/futex.h:88
> #3 =C2=A0wait_for_sessiond (sock_info=3D0xffffbef6b638 <global_apps= >) at
> lttng-ust-comm.c:1761
> #4 =C2=A0ust_listener_thread (arg=3D0xffffbef6b638 <global_apps>= ) at
> lttng-ust-comm.c:1832
> #5 =C2=A00x0000ffffbe9206a8 in start_thread (arg=3D0xffffc1bd8687) at =
> pthread_create.c:442
> #6 =C2=A00x0000ffffbe98801c in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
>
> Thread 2 (Thread 0xffffbdfce7e0 (LWP 560)):
> #0 =C2=A0syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38=
> #1 =C2=A00x0000ffffbeef1bb8 in lttng_ust_futex (val3=3D0, uaddr2=3D0x0= ,
> timeout=3D0x0, val=3D0, op=3D0, uaddr=3D0xffffbefd7000) at
> ../../../src/lib/lttng-ust/futex.h:56
> #2 =C2=A0lttng_ust_futex_async (op=3D0, val=3D0, timeout=3D0x0, uaddr2= =3D0x0, val3=3D0,
> uaddr=3D0xffffbefd7000) at ../../../src/lib/lttng-ust/futex.h:88
> #3 =C2=A0wait_for_sessiond (sock_info=3D0xffffbef695e0 <local_apps&= gt;) at
> lttng-ust-comm.c:1761
> #4 =C2=A0ust_listener_thread (arg=3D0xffffbef695e0 <local_apps>)= at
> lttng-ust-comm.c:1832
> #5 =C2=A00x0000ffffbe9206a8 in start_thread (arg=3D0xffffc1bd8687) at =
> pthread_create.c:442
> #6 =C2=A00x0000ffffbe98801c in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
>
> Thread 1 (Thread 0xffffbefcf460 (LWP 545)):
> #0 =C2=A0__strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asim= d.S:96
> #1 =C2=A00x0000ffffbe834bd0 in lttng_ust_tp_validate_event_name
> (tp=3D0xaaaab8f14de0
> <lttng_ust_tracepoint_hello_world___my_first_tracepoint>,
> tp=3D0xaaaab8f14de0
> <lttng_ust_tracepoint_hello_world___my_first_tracepoint>) at > tracepoint.c:143
> #2 =C2=A0add_callsite (tp=3D0xaaaab8f14de0
> <lttng_ust_tracepoint_hello_world___my_first_tracepoint>,
> lib=3D0xaaaae74fad30) at tracepoint.c:412
> #3 =C2=A0lib_register_callsites (lib=3D0xaaaae74fad30) at tracepoint.c= :552
> #4 =C2=A0lttng_ust_tracepoint_module_register (tracepoints_start=3D<= ;optimized
> out>, tracepoints_count=3D<optimized out>) at tracepoint.c:95= 6
> #5 =C2=A00x0000aaaab8758204 in lttng_ust.tracepoints.ptrs_init ()
> #6 =C2=A00x0000ffffbe8cb30c in call_init (env=3D<optimized out>,=
> argv=3D0xffffc1bd8c88, argc=3D1) at ../csu/libc-start.c:145
> #7 =C2=A0__libc_start_main_impl (main=3D0xaaaab867aabc <main>, a= rgc=3D1,
> argv=3D0xffffc1bd8c88, init=3D<optimized out>, fini=3D<optimi= zed out>,
> rtld_fini=3D<optimized out>, stack_end=3D<optimized out>) = at
> ../csu/libc-start.c:376
> #8 =C2=A00x0000aaaab867a7f0 in _start () at ../sysdeps/aarch64/start.S= :81
>
> Regards,
>
> Brian
--000000000000492929061d73f16f-- --===============1071897157144700149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============1071897157144700149==--