[ltt-dev] UST - Problems in recording trace on a current process

[pierre-marc.fournier@polymtl.ca (Pierre-Marc Fournier)]

Naren wrote:
> Hi Pierre,
> 
>>>So we have the answer to your problem. You cannot list the markers on your
>>>program (firefox) because it was not linked with libust. Linking a
> program to
>>>libust is essential in order to be able to trace it or to list markers.
> 
>>>There are two ways of doing this. Either you can link it with the gcc
>>>option -lust at compile time, or you can link it at runtime using
> LD_PRELOAD.
>>>For example:
> 
>>>LD_PRELOAD=/path/to/libust.so ./myprogram
> 
> I did a LD_PRELOAD on libust.so
> 
> Inside /usr/local/lib directory, i found three shared objects with the
> same name libust. I guess libust.so is the linker name and libust.so.0
> and libust.so.0.0.0 are fully qualified names with libust.so.0  being
> linked to libust.so.0 .0.0 .

In fact, libust.so is a linker script pointing to libust-initializer.o
and libust.so.0.0.0 (the "real" library). But you don't need to bother
about this. See below.

> 
> Having found that running LD_PRELOAD on libust.so, again unfortunately,
> gave this error. Moreover, the other alternative also gave the same one.
> 
>>>Another way to do the LD_PRELOAD trick is to use usttrace, which will
> do it
>>>automatically with -l:
> 
>>>usttrace -l ./myprogram
> 
> *ERROR: ld.so: object '/usr/local/lib/libust.so' from LD_PRELOAD cannot
> be preloaded: ignored.*
> *
> *
> *So, I tried LD_PRELOAD with libust.so.0.0.0, this time i didnt get any
> error.*

I see what happened. Indeed when you LD_PRELOAD, you should do it on
libust.so.0.0.0. This is my mistake. I am updating usttrace as well for
this. Thanks.

> *
> *
> *However, ustctl --list-markers /pid/ , I am getting segmentation fault.*
> *I did a strace on that, and found these interesting traces.*
> *
> *
> *
> *
> socket(PF_FILE, SOCK_STREAM, 0)         = 3
> *
> *connect(3, {sa_family=AF_FILE, path="/tmp/ust-app-socks/1709"}, 110) = 0*
> *send(3, "list_markers", 12, MSG_NOSIGNAL) = 12*
> *recv(3, "marker: metadata/core_marker_id "..., 1000, 0) = 1000*
> *--- SIGSEGV (Segmentation fault) @ 0 (0) ---*
> *+++ killed by SIGSEGV +++*
> 
> The full dump of strace can be found here http://pastebin.ca/1792101 . 
> 
> Is it a problem due to multiple shared objects, or does it necessitate
> another clean install of some libraries?
> 

I'm not sure what you could have done that would necessitate a clean
install. If you suspect your installation is dirty or composed of libs
of mixed versions, I suggest to do clean install as the situation can
result in segfaults.

But you might face a real bug. Based on the strace output, it is ustctl
that is segfaulting. Could you compile it with:

make clean
CFLAGS="-g3" ./configure
make
make install

Then run the same ustctl command within gdb and post the backtrace (bt
command) you get after the segfault.

Thanks!

pmf