From mboxrd@z Thu Jan  1 00:00:00 1970
From: pierre-marc.fournier@polymtl.ca (Pierre-Marc Fournier)
Date: Wed, 10 Feb 2010 10:26:01 -0500
Subject: [ltt-dev] UST - Problems in recording trace on a current process
In-Reply-To: <19fa8ef31002091650k3363add7s10be22658cfa8eec@mail.gmail.com>
References: <19fa8ef31002081349v36a13174m1a031048048fd45c@mail.gmail.com>	
	<201002091225.13893.pierre-marc.fournier@polymtl.ca>	
	<19fa8ef31002091240s57b513e0v81f524795b0f77ac@mail.gmail.com>	
	<201002091628.10137.pierre-marc.fournier@polymtl.ca>
	<19fa8ef31002091650k3363add7s10be22658cfa8eec@mail.gmail.com>
Message-ID: <4B72D009.2060702@polymtl.ca>

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