Project

General

Profile

Actions
Copy link

Bug #498

closed

Can 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 about 11 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Critical
Assignee:
-
Target version:
LTTng - 2.2
Start date:
03/27/2013
Due date:
% Done:

0%

Estimated time:

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.
Actions
Copy link
 #1

Updated by Mathieu Desnoyers about 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 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"
Actions
Copy link
 #2

Updated by Mathieu Desnoyers about 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

Actions
Copy link
 #3

Updated by Tan le tran about 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] #
Actions
Copy link
 #4

Updated by Mathieu Desnoyers about 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.

Actions
Copy link
 #5

Updated by Mathieu Desnoyers almost 11 years ago

Hi Tan,

Can you let us know if this issue has been fixed ?

Thanks,

Mathieu

Actions
Copy link
 #6

Updated by Tan le tran almost 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
Actions
Copy link
 #7

Updated by Mathieu Desnoyers almost 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 <>
Date: Tue Feb 26 15:25:18 2013 -0500

Use tp rcu link test in provider
Ensure we never trigger a null pointer exception.
Signed-off-by: Mathieu Desnoyers &lt;&gt;

commit fd9619bcf98bae43e3418b6c61d2727d49d7d54b
Author: Mathieu Desnoyers <>
Date: Tue Feb 26 15:16:57 2013 -0500

Remove direct dependency of probes on urcu-bp
The 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 &lt;&gt;

--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Actions
Copy link
 #8

Updated by Tan le tran almost 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)
Actions
Copy link
 #9

Updated by Mathieu Desnoyers almost 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

Actions
Copy link
 #10

Updated by Mathieu Desnoyers almost 11 years ago

Hi Tan,

Can you confirm that this bug no longer appears ?

Thanks,

Mathieu

Actions
Copy link
 #11

Updated by Tan le tran almost 11 years ago

Hi Mathieu,

I tried it again and the problem is no longer there .
Thanks,
Tan

Actions
Copy link
 #12

Updated by Mathieu Desnoyers almost 11 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #13

Updated by Suraj Bagad over 10 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

Actions
Copy link
 #14

Updated by Mathieu Desnoyers over 10 years ago

Did you run "ldconfig" as root after installing each package ?

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Actions
Copy link

Also available in: Atom PDF