Bug #498
closedCan not successfully launch instrumented app (that are compiled with lttng 2.1) when latest lttng (origin/master) is loaded and a session is active
Added by Mathieu Desnoyers over 11 years ago. Updated over 11 years ago.
0%
Description
Problem Description:
====================
* When launching an instrumented app (which is compiled with lttng 2.1) on a
system that has lttng latest origin/master loaded (and an active session
is present), then the instrumented app either segfault or gives the following
error message:
"error while loading shared libraries: liburcu-bp.so.1: cannot open shared
object file: No such file or directory"
The instrumented app segfault when the following commits were used:
userspace : 8a97780 (HEAD, origin/stable-0.7) Fix: tests/api.h use cpuset.h
lttng-tools : 8f3f773 (HEAD, origin/master, origin/HEAD, globalBuffer) Fix: lttng UI ...
lttng-ust : d3db6a4 (HEAD, origin/master, origin/HEAD) Performance: add unlikely ...
The instrumented app fails to launch with error "error while loading shared libraries:
liburcu-bp.so.1: cannot open shared object file: No such file or directory"
when the following commit were used:
userspace : d107390 (HEAD, origin/master, origin/HEAD, globalBuffer) Add tab to output ...
lttng-tools : e2ad3b4 (HEAD, origin/master, origin/HEAD, globalBuffer) Add demo README
lttng-ust : 9f9ee9c (HEAD, origin/master, origin/HEAD, globalBuffer) Fix: UST context activation
Is problem reproducible ?
=========================
Yes
How to reproduce (if reproducible):
===================================
Scenario1 (when usersapce 0.7 is used)
0)_ Use the following commits:
userspace : 8a97780 (HEAD, origin/stable-0.7) Fix: tests/api.h use cpuset.h
lttng-tools : 8f3f773 (HEAD, origin/master, origin/HEAD, globalBuffer) Fix: lttng UI ...
lttng-ust : d3db6a4 (HEAD, origin/master, origin/HEAD) Performance: add unlikely ...
1)_ Compile an instrumented app with lttng 2.1 library
2)_ Load lttng from origin/master branch
3)_ Launch the instr app (from step-1)
lttng list -u #-- shows that the app is registered to sessionD
4)_ lttng create s
lttng enable-event -u "com*"
lttng start
5)_ The app will segfault as soon as the session is started.
6)_ Relaunch the app again
The app will segfault right away.
Scenario2 (when latest origin/master userspace is used)
0)_ Use the following commits:
userspace : d107390 (HEAD, origin/master, origin/HEAD, globalBuffer) Add tab to output ...
lttng-tools : e2ad3b4 (HEAD, origin/master, origin/HEAD, globalBuffer) Add demo README
lttng-ust : 9f9ee9c (HEAD, origin/master, origin/HEAD, globalBuffer) Fix: UST context activation
1)_ Compile an instrumented app with lttng 2.1 library
2)_ Load lttng from origin/master branch
3)_ Launch the instr app (from step-1)
The app fail to launch with the following error:
"error while loading shared libraries: liburcu-bp.so.1: cannot
open shared object file: No such file or directory"
Commit used:
============
Please see description above.
Updated by Mathieu Desnoyers over 11 years ago
Copying entry for specifically addressing dynamic linker error:
Scenario2 (when latest origin/master userspace is used)
0)_ Use the following commits:
userspace : d107390 (HEAD, origin/master, origin/HEAD, globalBuffer) Add tab to output ...
lttng-tools : e2ad3b4 (HEAD, origin/master, origin/HEAD, globalBuffer) Add demo README
lttng-ust : 9f9ee9c (HEAD, origin/master, origin/HEAD, globalBuffer) Fix: UST context activation1)_ Compile an instrumented app with lttng 2.1 library
2)_ Load lttng from origin/master branch
3)_ Launch the instr app (from step-1)
The app fail to launch with the following error:
"error while loading shared libraries: liburcu-bp.so.1: cannot
open shared object file: No such file or directory"Updated by Mathieu Desnoyers over 11 years ago
It's possible that you forgot to run "ldconfig" after installing lttng-ust from the master branch at step 2.
I could not reproduce your issue here.. here is an example of what I did. Having the same log of these steps on your side would be helpful, especially when you get the linker error.
Using "TestApp_type1", which is linked to liblttng-ust with "-l" passed
to the linker. (Hopefully the same app setup as yours ?)
with userspace rcu stable-0.7:
with with lttng-ust stable-2.1:
compudj@thinkos:~/test/ust/ex2/Example_Instrumented_Apps/TestApp_type$ ldd TestApp_type1
linux-vdso.so.1 => (0x00007fffb5fff000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10fa48d000)
liblttng-ust.so.0 => /usr/local/lib/liblttng-ust.so.0 (0x00007f10fa255000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f10f9f4d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10f9ccb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10f9ab5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10f972a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f10f9522000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10f9306000)
/lib64/ld-linux-x86-64.so.2 (0x00007f10fa6b9000)
liblttng-ust-tracepoint.so.0 => /usr/local/lib/liblttng-ust-tracepoint.so.0 (0x00007f10f90f8000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f10f8ef3000)
liburcu-bp.so.1 => /usr/local/lib/liburcu-bp.so.1 (0x00007f10f8ced000)
liburcu-cds.so.1 => /usr/local/lib/liburcu-cds.so.1 (0x00007f10f8ae6000)
liburcu-common.so.1 => /usr/local/lib/liburcu-common.so.1 (0x00007f10f88e4000)
Issue "make uninstall" for both userspace rcu and lttng-ust to remove
the "old" .so. Without recompiling the app, we see that liblttng-ust is
"not found":
compudj@thinkos:~/test/ust/ex2/Example_Instrumented_Apps/TestApp_type$ ldd TestApp_type1
linux-vdso.so.1 => (0x00007fff779ff000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe238e44000)
liblttng-ust.so.0 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe238b3c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe2388ba000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe2386a4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe238319000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe238111000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe237ef5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe239070000)
Then update the trees, and install the new versions in the system, we
see that the news libs are seen (application not recompiled):
with userspace rcu d10739031cbd3078c97d3f3b30984fa84a9b6951:
with with lttng-ust efbad5cc87395d00fa1d578ae211aee431fa3b4a:
with lttng-tools 500c23938e22e43ca5518790d638ef6259a296d8:
compudj@thinkos:~/test/ust/ex2/Example_Instrumented_Apps/TestApp_type$ ldd TestApp_type1
linux-vdso.so.1 => (0x00007ffff0de5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f66a77b3000)
liblttng-ust.so.0 => /usr/local/lib/liblttng-ust.so.0 (0x00007f66a756d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f66a7265000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f66a6fe3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f66a6dcd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f66a6a42000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f66a683a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f66a661e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f66a79df000)
liblttng-ust-tracepoint.so.0 => /usr/local/lib/liblttng-ust-tracepoint.so.0 (0x00007f66a6408000)
liburcu-bp.so.2 => /usr/local/lib/liburcu-bp.so.2 (0x00007f66a6202000)
liburcu-cds.so.2 => /usr/local/lib/liburcu-cds.so.2 (0x00007f66a5ffb000)
liburcu-common.so.2 => /usr/local/lib/liburcu-common.so.2 (0x00007f66a5df7000)
Then, without tracing:
compudj@thinkos:~/test/ust/ex2/Example_Instrumented_Apps/TestApp_type$ ./TestApp_type1 1
com_ericsson_cba_trace_testapp_lowtraf 1/s: this is the 0th time, at: 21:23:55, 229689735100000----------
21:23:55end of program
Updated by Tan le tran over 11 years ago
Currently our target node has the lttng2.2.0rc1 installed (using the same commits as specified
at the top of this report).
When "ldd" on the old version of TestApp_type1 (the one that got
compiled against lttng2.1), we have the following output:
[SC-1:Node16 Tue Apr 16 13:47:01/home/test_apps/1.1PRA] # lddconfig
-bash: lddconfig: command not found
[SC-1:Node16 Tue Apr 16 13:47:05/home/test_apps/1.1PRA] # ldconfig
[SC-1:Node16 Tue Apr 16 13:47:09/home/test_apps/1.1PRA] # ldd TestApp_type1
linux-vdso.so.1 => (0x00007fff0cf9a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1222132000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1221f2d000)
liblttng-ust.so.0 => /usr/lib64/liblttng-ust.so.0 (0x00007f1221cca000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f12219c0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1221746000)
libc.so.6 => /lib64/libc.so.6 (0x00007f12213d2000)
librt.so.1 => /lib64/librt.so.1 (0x00007f12211c9000)
liburcu-bp.so.1 => not found
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1220fb2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1222358000)
liblttng-ust-tracepoint.so.0 => /usr/lib64/liblttng-ust-tracepoint.so.0 (0x00007f1220da4000)
liburcu-bp.so.2 => /usr/lib64/liburcu-bp.so.2 (0x00007f1220b9b000)
liburcu-cds.so.2 => /usr/lib64/liburcu-cds.so.2 (0x00007f1220990000)
liburcu-common.so.2 => /usr/lib64/liburcu-common.so.2 (0x00007f122078a000)
[SC-1:Node16 Tue Apr 16 13:47:13/home/test_apps/1.1PRA] # ls -ltr /usr/lib64/ |grep liburcu
-rwxr-xr-x 1 root root 31344 Apr 3 09:11 liburcu.so.2.0.0
-rwxr-xr-x 1 root root 35480 Apr 3 09:11 liburcu-signal.so.2.0.0
-rwxr-xr-x 1 root root 31384 Apr 3 09:11 liburcu-qsbr.so.2.0.0
-rwxr-xr-x 1 root root 31352 Apr 3 09:11 liburcu-mb.so.2.0.0
-rwxr-xr-x 1 root root 18528 Apr 3 09:11 liburcu-common.so.2.0.0
-rwxr-xr-x 1 root root 43312 Apr 3 09:11 liburcu-cds.so.2.0.0
-rwxr-xr-x 1 root root 31304 Apr 3 09:11 liburcu-bp.so.2.0.0
lrwxrwxrwx 1 root root 21 Apr 3 10:45 liburcu-qsbr.so.2 -> liburcu-qsbr.so.2.0.0
lrwxrwxrwx 1 root root 21 Apr 3 10:45 liburcu-qsbr.so -> liburcu-qsbr.so.2.0.0
lrwxrwxrwx 1 root root 19 Apr 3 10:45 liburcu-mb.so.2 -> liburcu-mb.so.2.0.0
lrwxrwxrwx 1 root root 19 Apr 3 10:45 liburcu-mb.so -> liburcu-mb.so.2.0.0
lrwxrwxrwx 1 root root 23 Apr 3 10:45 liburcu-common.so.2 -> liburcu-common.so.2.0.0
lrwxrwxrwx 1 root root 23 Apr 3 10:45 liburcu-common.so -> liburcu-common.so.2.0.0
lrwxrwxrwx 1 root root 20 Apr 3 10:45 liburcu-cds.so.2 -> liburcu-cds.so.2.0.0
lrwxrwxrwx 1 root root 20 Apr 3 10:45 liburcu-cds.so -> liburcu-cds.so.2.0.0
lrwxrwxrwx 1 root root 19 Apr 3 10:45 liburcu-bp.so.2 -> liburcu-bp.so.2.0.0
lrwxrwxrwx 1 root root 19 Apr 3 10:45 liburcu-bp.so -> liburcu-bp.so.2.0.0
lrwxrwxrwx 1 root root 16 Apr 3 10:45 liburcu.so.2 -> liburcu.so.2.0.0
lrwxrwxrwx 1 root root 16 Apr 3 10:45 liburcu.so -> liburcu.so.2.0.0
lrwxrwxrwx 1 root root 23 Apr 3 10:45 liburcu-signal.so.2 -> liburcu-signal.so.2.0.0
lrwxrwxrwx 1 root root 23 Apr 3 10:45 liburcu-signal.so -> liburcu-signal.so.2.0.0
[SC-1:Node16 Tue Apr 16 13:49:59/home/test_apps/1.1PRA] #
From the above, the library "liburcu-bp.so.1" is not comming with the new installation.
Can that be something that we have specified during compilation ?
(we are investigating).
When "ldd" on the TestApp_type1 (compiled against lttng 2.2.0rc1), the following output
is seen:
[SC-1:Node16 Tue Apr 16 14:08:02/home/test_apps] # ldd TestApp_type1
linux-vdso.so.1 => (0x00007ffff4c8e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f45a187c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f45a1677000)
liblttng-ust.so.0 => /usr/lib64/liblttng-ust.so.0 (0x00007f45a1414000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f45a110a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f45a0e90000)
libc.so.6 => /lib64/libc.so.6 (0x00007f45a0b1c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f45a0913000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f45a06fc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f45a1aa2000)
liblttng-ust-tracepoint.so.0 => /usr/lib64/liblttng-ust-tracepoint.so.0 (0x00007f45a04ee000)
liburcu-bp.so.2 => /usr/lib64/liburcu-bp.so.2 (0x00007f45a02e6000)
liburcu-cds.so.2 => /usr/lib64/liburcu-cds.so.2 (0x00007f45a00da000)
liburcu-common.so.2 => /usr/lib64/liburcu-common.so.2 (0x00007f459fed5000)
[SC-1:Node16 Tue Apr 16 14:08:08/home/test_apps] #
Updated by Mathieu Desnoyers over 11 years ago
It looks like you linked your application (or probe provider) explicitly against liburcu-bp.so, am I correct ?
The dependency should not be explicit, but rather done through liblttng-ust.so.
Updated by Mathieu Desnoyers over 11 years ago
Hi Tan,
Can you let us know if this issue has been fixed ?
Thanks,
Mathieu
Updated by Tan le tran over 11 years ago
Hi Mathieu, We still have this issue. Note that this issue is only encountered when latest rcu version is used. Based on the confirmation that lttng2.2 will be released with rcu 0.7 we no longer test with latest rcu version but we use only rcu 0.7 instead. So, technically, it is no longer a show stopper for us. Therefore, you can have this bug closed if you wish and we will create a new one later in case we see it again when we start basing on newer rcu version. Regards, Tan
Updated by Mathieu Desnoyers over 11 years ago
It is important to solve this issue. I think the issue is caused by
lttng-ust 2.1 (not liburcu), so it is important to ensure its cause is
well understood and fixed, so lttng-ust and urcu upgrades go smoothly in
the future.
In the bug report, you said your application was compiled against
lttng-ust 2.1. Which commit id was it exactly ?
Especially, did it include those commits ?
commit 3ac4bd8ab309129f091ac180fb68e49cfc23dc8b
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: Tue Feb 26 15:25:18 2013 -0500
Use tp rcu link test in providerEnsure we never trigger a null pointer exception.Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>commit fd9619bcf98bae43e3418b6c61d2727d49d7d54b
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: Tue Feb 26 15:16:57 2013 -0500
Remove direct dependency of probes on urcu-bpThe filter feature added a direct dependency of probes providers against
urcu-bp .so, while linking them against liblttng-ust should suffice. Fix
this by using the tracepoint.h wrapper for rcu_dereference().Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Updated by Tan le tran over 11 years ago
Hi Mathieu,
No, our lttng2.1 build does not include the commit you were mentioned.
here are the info:
commits used for lttng2.1:
==========================
userspace-rcu da9bed2 (HEAD, tag: v0.7.6) Version 0.7.6
lttng-ust 05356aa (HEAD, tag: v2.1.1) Version 2.1.1
lttng-tools 959f036 (HEAD, tag: v2.1.1) Update version to v2.1.1
babeltrace 6d204f6 (HEAD, tag: v1.0.2) Version 1.0.2
commits used for lttng2.2_rcu-0.7:
==================================
userspace-rcu 56e676d (HEAD, origin/stable-0.7) Document: rculfhash destroy and resize ...
lttng-ust 9ac8c21 (HEAD, tag: v2.2.0-rc2, origin/master, origin/HEAD) Version 2.2.0-rc2
lttng-tools afeab17 (HEAD, tag: v2.2.0-rc2, origin/master, origin/HEAD) Update version to v2.2.0-rc2
babeltrace 5bfcad9 (HEAD, origin/master, origin/HEAD) Fix: handling of empty streams
commit used for lttng2.2_latest_rcu:
====================================
babeltrace 5bfcad9 (HEAD, origin/master, origin/HEAD, master) Fix: handling of empty streams
lttng-tools 0a9c649 (HEAD, origin/master, origin/HEAD, master) Fix: split UST per UID/PID default values
lttng-ust 9ac8c21 (HEAD, tag: v2.2.0-rc2, origin/master, origin/HEAD, master) Version 2.2.0-rc2
userspace-rcu c13c2e5 (HEAD, origin/master, origin/HEAD, master) urcu-bp: introduce struct urcu_gp
When target machine is loaded with <lttng2.2_rcu-0.7>:
======================================================
"ls -ltr /usr/lib64/ |grep liburcu" gives:
23072 May 9 10:56 liburcu.so.1.0.0
23112 May 9 10:56 liburcu-signal.so.1.0.0
23080 May 9 10:56 liburcu-qsbr.so.1.0.0
23080 May 9 10:56 liburcu-mb.so.1.0.0
10336 May 9 10:56 liburcu-common.so.1.0.0
26928 May 9 10:56 liburcu-cds.so.1.0.0
27224 May 9 10:56 liburcu-bp.so.1.0.0
19 May 9 11:17 liburcu-mb.so.1 -> liburcu-mb.so.1.0.0
19 May 9 11:17 liburcu-mb.so -> liburcu-mb.so.1.0.0
23 May 9 11:17 liburcu-common.so.1 -> liburcu-common.so.1.0.0
23 May 9 11:17 liburcu-common.so -> liburcu-common.so.1.0.0
20 May 9 11:17 liburcu-cds.so.1 -> liburcu-cds.so.1.0.0
20 May 9 11:17 liburcu-cds.so -> liburcu-cds.so.1.0.0
19 May 9 11:17 liburcu-bp.so.1 -> liburcu-bp.so.1.0.0
19 May 9 11:17 liburcu-bp.so -> liburcu-bp.so.1.0.0
16 May 9 11:17 liburcu.so.1 -> liburcu.so.1.0.0
16 May 9 11:17 liburcu.so -> liburcu.so.1.0.0
23 May 9 11:17 liburcu-signal.so.1 -> liburcu-signal.so.1.0.0
23 May 9 11:17 liburcu-signal.so -> liburcu-signal.so.1.0.0
21 May 9 11:17 liburcu-qsbr.so.1 -> liburcu-qsbr.so.1.0.0
21 May 9 11:17 liburcu-qsbr.so -> liburcu-qsbr.so.1.0.0
"hello" from lttng-ust/tests/hello/.libs after building <lttng2.1>.
"ldd hello" gives:
linux-vdso.so.1 => (0x00007fffac9ff000)
liblttng-ust.so.0 => /usr/lib64/liblttng-ust.so.0 (0x00007f1c730d0000)
liblttng-ust-tracepoint.so.0 => /usr/lib64/liblttng-ust-tracepoint.so.0 (0x00007f1c72eb8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f1c72caf000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f1c72aaa000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1c728a6000)
liburcu-bp.so.1 => /usr/lib64/liburcu-bp.so.1 (0x00007f1c7269e000)
liburcu-cds.so.1 => /usr/lib64/liburcu-cds.so.1 (0x00007f1c72497000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1c7227a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1c71f05000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1c73339000)
liburcu-common.so.1 => /usr/lib64/liburcu-common.so.1 (0x00007f1c71d02000)
NOTE: This is fixed by bug-497 (we used to see segfault when launching the app)
When target machine is loaded with <lttng2.2_latest_rcu>:
=========================================================
"ls -ltr /usr/lib64/ |grep liburcu" gives:
23440 May 9 09:13 liburcu.so.2.0.0
27544 May 9 09:13 liburcu-signal.so.2.0.0
23448 May 9 09:13 liburcu-qsbr.so.2.0.0
23448 May 9 09:13 liburcu-mb.so.2.0.0
14432 May 9 09:13 liburcu-common.so.2.0.0
26936 May 9 09:13 liburcu-cds.so.2.0.0
27496 May 9 09:13 liburcu-bp.so.2.0.0
16 May 9 09:39 liburcu.so.2 -> liburcu.so.2.0.0
16 May 9 09:39 liburcu.so -> liburcu.so.2.0.0
23 May 9 09:39 liburcu-signal.so.2 -> liburcu-signal.so.2.0.0
23 May 9 09:39 liburcu-signal.so -> liburcu-signal.so.2.0.0
21 May 9 09:39 liburcu-qsbr.so.2 -> liburcu-qsbr.so.2.0.0
21 May 9 09:39 liburcu-qsbr.so -> liburcu-qsbr.so.2.0.0
19 May 9 09:39 liburcu-mb.so.2 -> liburcu-mb.so.2.0.0
19 May 9 09:39 liburcu-mb.so -> liburcu-mb.so.2.0.0
23 May 9 09:39 liburcu-common.so.2 -> liburcu-common.so.2.0.0
23 May 9 09:39 liburcu-common.so -> liburcu-common.so.2.0.0
20 May 9 09:39 liburcu-cds.so.2 -> liburcu-cds.so.2.0.0
20 May 9 09:39 liburcu-cds.so -> liburcu-cds.so.2.0.0
19 May 9 09:39 liburcu-bp.so.2 -> liburcu-bp.so.2.0.0
19 May 9 09:39 liburcu-bp.so -> liburcu-bp.so.2.0.0
"hello" from lttng-ust/tests/hello/.libs after building <lttng2.1>.
"ldd hello" gives:
linux-vdso.so.1 => (0x00007fffcfdff000)
liblttng-ust.so.0 => /usr/lib64/liblttng-ust.so.0 (0x00007f6637623000)
liblttng-ust-tracepoint.so.0 => /usr/lib64/liblttng-ust-tracepoint.so.0 (0x00007f663740c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f6637203000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6636ffe000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f6636df9000)
liburcu-bp.so.1 => not found
liburcu-cds.so.1 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6636bdb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6636867000)
liburcu-bp.so.2 => /usr/lib64/liburcu-bp.so.2 (0x00007f6636660000)
liburcu-cds.so.2 => /usr/lib64/liburcu-cds.so.2 (0x00007f6636458000)
/lib64/ld-linux-x86-64.so.2 (0x00007f663787d000)
liburcu-common.so.2 => /usr/lib64/liburcu-common.so.2 (0x00007f6636254000)
Updated by Mathieu Desnoyers over 11 years ago
OK, can you please try to rebuild your application against the latest
stable-2.1/userspace RCU 0.7 and see if it works fine when you migrate
to userspace RCU master branch ?
If that works fine, we'll be able to close this bug: it means it was
fixed already by commits in stable-2.1.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Updated by Mathieu Desnoyers over 11 years ago
Hi Tan,
Can you confirm that this bug no longer appears ?
Thanks,
Mathieu
Updated by Tan le tran over 11 years ago
Hi Mathieu,
I tried it again and the problem is no longer there .
Thanks,
Tan
Updated by Mathieu Desnoyers over 11 years ago
- Status changed from Feedback to Resolved
Updated by Suraj Bagad over 11 years ago
Hi Mathieu
I am trying to use the LTTNg ust on centOS 6.4 for which iam getting same error still.
I earlier had latest stable version
LTTng-tools 2.2.3 , LTTng-UST 2.2.1, liburcu 0.7.7
I was getting same error as mentioned in this thread
"./sample: error while loading shared libraries: liblttng-ust.so.0: cannot open shared object file: No such file or directory" while executing the easy-ust sample program.
So by reading this thread i reverted to version
LTTng-tools 2.1.2 , LTTng-UST 2.1.4, liburcu 0.7.0
but still i am getting the same error
can u please let me know why this issue is coming
CentOS Linux DEV.CentOS6.4 2.6.32-358.6.1
Regards,
Suraj
Updated by Mathieu Desnoyers over 11 years ago
Did you run "ldconfig" as root after installing each package ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com