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

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

[Naren]

Hi,

When executing ustctl in manual mode to record a trace on a current process,
i am getting the following error.

*Error: connect: No such file or directory (../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 1989*
*error while trying to list markers for PID 1989*

Preceding the command execution

1. I've already created ustsocks,socks and trace under tmp directory.
2. Started the demon ustd
3. gave this command "ustctl --list-markers 1989" . On giving this command,
i got the above mentioned error. 1989 is the pid of the process that was
supposed to be tracked.
4. I have also verified to determine ustd is running or not. Its running on
tty "pts/01".

I've also been facing problems in usttrace after the installation of urcu
0.4

please check this link for the error snapshot .. http://pastebin.ca/1790628

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100208/7d8449aa/attachment-0003.htm>

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

[Naren]

Hi,

When executing ustctl in manual mode to record a trace on a current process,
i am getting the following error.

*Error: connect: No such file or directory (../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 1989*
*error while trying to list markers for PID 1989*

Preceding the command execution

1. I've already created ustsocks,socks and trace under tmp directory.
2. Started the demon ustd
3. gave this command "ustctl --list-markers 1989" . On giving this command,
i got the above mentioned error. 1989 is the pid of the process that was
supposed to be tracked.
4. I have also verified to determine ustd is running or not. Its running on
tty "pts/01".

I've also been facing problems in usttrace after the installation of urcu
0.4

please check this link for the error snapshot .. http://pastebin.ca/1790628

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100208/7d8449aa/attachment-0002.htm>

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

[Pierre-Marc Fournier]

Hi,

>
> *Error: connect: No such file or directory (../libustcomm/ustcomm.c:452)*
> *ustcmd_send_cmd: could not connect to PID 1989*
> *error while trying to list markers for PID 1989*

Please specify whether you are running UST 0.1 or the latest git. Lots of 
things have changed lately in the git.

>
> Preceding the command execution
>
> 1. I've already created ustsocks,socks and trace under tmp directory.
> 2. Started the demon ustd
> 3. gave this command "ustctl --list-markers 1989" . On giving this command,
> i got the above mentioned error. 1989 is the pid of the process that was
> supposed to be tracked.
> 4. I have also verified to determine ustd is running or not. Its running on
> tty "pts/01".
>
> I've also been facing problems in usttrace after the installation of urcu
> 0.4

If you are using UST 0.1, this is normal. Quoting the README, "-> This release 
was tested with liburcu v0.3.4". liburcu 0.4 is not backward compatible so 
things break. But there is a recent commit in the ust git that switches to 
the new urcu API. If you _are_ using the latest UST git, then there is a 
problem.

Again, please specify what version you are using.

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

[Naren]

Hi,
Thanks for the link.

Running autoconf on configure.ac gives be the following error
http://pastebin.ca/1790743.

The complete autoconf console output http://pastebin.ca/1790762

<http://pastebin.ca/1790762>Regards
Naren

On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> On February 8, 2010 17:28:43 you wrote:
> > Hi,
> >
> > No, i haven't pulled the latest version of ust from git. I've been using
> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can you
> > specify the git url for UST as i cannot locate it.
>
> git://git.dorsal.polymtl.ca/git/ust.git
>
> Gitweb:
> http://git.dorsal.polymtl.ca (project: ust)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/58e0b06c/attachment-0002.htm>

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

[Naren]

Hi,
Thanks for the link.

Running autoconf on configure.ac gives be the following error
http://pastebin.ca/1790743.

The complete autoconf console output http://pastebin.ca/1790762

<http://pastebin.ca/1790762>Regards
Naren

On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> On February 8, 2010 17:28:43 you wrote:
> > Hi,
> >
> > No, i haven't pulled the latest version of ust from git. I've been using
> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can you
> > specify the git url for UST as i cannot locate it.
>
> git://git.dorsal.polymtl.ca/git/ust.git
>
> Gitweb:
> http://git.dorsal.polymtl.ca (project: ust)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/58e0b06c/attachment-0003.htm>

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

[soumyakanti chakraborty]

On Tue, Feb 9, 2010 at 12:54 AM, Naren <tracemein at gmail.com> wrote:

> Hi,
> Thanks for the link.
>
> Running autoconf on configure.ac gives be the following error
> http://pastebin.ca/1790743.
>

Naren, First install the package called *libtools *which adds "*libtools.m4*"
under "*/usr/share/aclocal"*
*
*
*Then go to your ust directory and run "./bootstrap" . After the successful
completion of this command run autoconf on your configure.ac file. I think
this time you will not face any errors.*

Regards,
Soumya


>
> The complete autoconf console output http://pastebin.ca/1790762
>
> <http://pastebin.ca/1790762>Regards
> Naren
>
> On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
> pierre-marc.fournier at polymtl.ca> wrote:
>
>> On February 8, 2010 17:28:43 you wrote:
>> > Hi,
>> >
>> > No, i haven't pulled the latest version of ust from git. I've been using
>> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can
>> you
>> > specify the git url for UST as i cannot locate it.
>>
>> git://git.dorsal.polymtl.ca/git/ust.git
>>
>> Gitweb:
>> http://git.dorsal.polymtl.ca (project: ust)
>>
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/ce670409/attachment-0003.htm>

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

[soumyakanti chakraborty]

On Tue, Feb 9, 2010 at 12:54 AM, Naren <tracemein at gmail.com> wrote:

> Hi,
> Thanks for the link.
>
> Running autoconf on configure.ac gives be the following error
> http://pastebin.ca/1790743.
>

Naren, First install the package called *libtools *which adds "*libtools.m4*"
under "*/usr/share/aclocal"*
*
*
*Then go to your ust directory and run "./bootstrap" . After the successful
completion of this command run autoconf on your configure.ac file. I think
this time you will not face any errors.*

Regards,
Soumya


>
> The complete autoconf console output http://pastebin.ca/1790762
>
> <http://pastebin.ca/1790762>Regards
> Naren
>
> On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
> pierre-marc.fournier at polymtl.ca> wrote:
>
>> On February 8, 2010 17:28:43 you wrote:
>> > Hi,
>> >
>> > No, i haven't pulled the latest version of ust from git. I've been using
>> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can
>> you
>> > specify the git url for UST as i cannot locate it.
>>
>> git://git.dorsal.polymtl.ca/git/ust.git
>>
>> Gitweb:
>> http://git.dorsal.polymtl.ca (project: ust)
>>
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/ce670409/attachment-0002.htm>

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

[soumyakanti chakraborty]

Hi Pierre

I am still getting the same errors during the tracing of a particular
process with specific pid's -

*ustctl[1605/1605]: Error: connect: No such file or directory (in
ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 1283*
*error while trying to list markers for PID 1283*

I am using the latest version of UST from the git and *urcu-0.4.0. *Please
let me know if I am doing anything wrong.

Regards,
Soumya

On Tue, Feb 9, 2010 at 2:37 AM, soumyakanti chakraborty <
soumyakanti.chakraborty at gmail.com> wrote:

>
> On Tue, Feb 9, 2010 at 12:54 AM, Naren <tracemein at gmail.com> wrote:
>
>> Hi,
>> Thanks for the link.
>>
>> Running autoconf on configure.ac gives be the following error
>> http://pastebin.ca/1790743.
>>
>
> Naren, First install the package called *libtools *which adds "*
> libtools.m4*" under "*/usr/share/aclocal"*
> *
> *
> *Then go to your ust directory and run "./bootstrap" . After the
> successful completion of this command run autoconf on your configure.acfile. I think this time you will not face any errors.
> *
>
> Regards,
> Soumya
>
>
>>
>> The complete autoconf console output http://pastebin.ca/1790762
>>
>> <http://pastebin.ca/1790762>Regards
>> Naren
>>
>> On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
>> pierre-marc.fournier at polymtl.ca> wrote:
>>
>>> On February 8, 2010 17:28:43 you wrote:
>>> > Hi,
>>> >
>>> > No, i haven't pulled the latest version of ust from git. I've been
>>> using
>>> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can
>>> you
>>> > specify the git url for UST as i cannot locate it.
>>>
>>> git://git.dorsal.polymtl.ca/git/ust.git
>>>
>>> Gitweb:
>>> http://git.dorsal.polymtl.ca (project: ust)
>>>
>>
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/6e14ead2/attachment-0003.htm>

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

[soumyakanti chakraborty]

Hi Pierre

I am still getting the same errors during the tracing of a particular
process with specific pid's -

*ustctl[1605/1605]: Error: connect: No such file or directory (in
ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 1283*
*error while trying to list markers for PID 1283*

I am using the latest version of UST from the git and *urcu-0.4.0. *Please
let me know if I am doing anything wrong.

Regards,
Soumya

On Tue, Feb 9, 2010 at 2:37 AM, soumyakanti chakraborty <
soumyakanti.chakraborty at gmail.com> wrote:

>
> On Tue, Feb 9, 2010 at 12:54 AM, Naren <tracemein at gmail.com> wrote:
>
>> Hi,
>> Thanks for the link.
>>
>> Running autoconf on configure.ac gives be the following error
>> http://pastebin.ca/1790743.
>>
>
> Naren, First install the package called *libtools *which adds "*
> libtools.m4*" under "*/usr/share/aclocal"*
> *
> *
> *Then go to your ust directory and run "./bootstrap" . After the
> successful completion of this command run autoconf on your configure.acfile. I think this time you will not face any errors.
> *
>
> Regards,
> Soumya
>
>
>>
>> The complete autoconf console output http://pastebin.ca/1790762
>>
>> <http://pastebin.ca/1790762>Regards
>> Naren
>>
>> On Mon, Feb 8, 2010 at 11:44 PM, Pierre-Marc Fournier <
>> pierre-marc.fournier at polymtl.ca> wrote:
>>
>>> On February 8, 2010 17:28:43 you wrote:
>>> > Hi,
>>> >
>>> > No, i haven't pulled the latest version of ust from git. I've been
>>> using
>>> > UST 0.1 from the location http://lttng.org/files/ust/releases/ . Can
>>> you
>>> > specify the git url for UST as i cannot locate it.
>>>
>>> git://git.dorsal.polymtl.ca/git/ust.git
>>>
>>> Gitweb:
>>> http://git.dorsal.polymtl.ca (project: ust)
>>>
>>
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/6e14ead2/attachment-0002.htm>

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

[Pierre-Marc Fournier]

soumyakanti chakraborty wrote:
> Hi Pierre
> 
> I am still getting the same errors during the tracing of a particular
> process with specific pid's - 
> 
> /ustctl[1605/1605]: Error: connect: No such file or directory (in
> ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)/
> /ustcmd_send_cmd: could not connect to PID 1283/
> /error while trying to list markers for PID 1283/

I'm unable to reproduce the problem. Please make sure the new ust was
completely installed with "make install" (older versions of the libs
lying around could cause this). Also, try to run ustctl with strace.
This will tell what socket file it's trying to open. You can then go
check if the socket file is actually where it's looking for it.

Thanks!

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

[Naren]

Hi,

Somuya... thanks for the heads up.

Autoconf worked but unfortunately "make" fails. It gives this error
http://pastebin.ca/1791368 .

Regards,
Naren

On Tue, Feb 9, 2010 at 6:45 AM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> soumyakanti chakraborty wrote:
> > Hi Pierre
> >
> > I am still getting the same errors during the tracing of a particular
> > process with specific pid's -
> >
> > /ustctl[1605/1605]: Error: connect: No such file or directory (in
> > ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)/
> > /ustcmd_send_cmd: could not connect to PID 1283/
> > /error while trying to list markers for PID 1283/
>
> I'm unable to reproduce the problem. Please make sure the new ust was
> completely installed with "make install" (older versions of the libs
> lying around could cause this). Also, try to run ustctl with strace.
> This will tell what socket file it's trying to open. You can then go
> check if the socket file is actually where it's looking for it.
>
> Thanks!
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/652d931c/attachment-0003.htm>

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

[Naren]

Hi,

Somuya... thanks for the heads up.

Autoconf worked but unfortunately "make" fails. It gives this error
http://pastebin.ca/1791368 .

Regards,
Naren

On Tue, Feb 9, 2010 at 6:45 AM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> soumyakanti chakraborty wrote:
> > Hi Pierre
> >
> > I am still getting the same errors during the tracing of a particular
> > process with specific pid's -
> >
> > /ustctl[1605/1605]: Error: connect: No such file or directory (in
> > ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)/
> > /ustcmd_send_cmd: could not connect to PID 1283/
> > /error while trying to list markers for PID 1283/
>
> I'm unable to reproduce the problem. Please make sure the new ust was
> completely installed with "make install" (older versions of the libs
> lying around could cause this). Also, try to run ustctl with strace.
> This will tell what socket file it's trying to open. You can then go
> check if the socket file is actually where it's looking for it.
>
> Thanks!
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/652d931c/attachment-0002.htm>

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

[Douglas Santos]

Quoting Naren <tracemein at gmail.com>:
> Autoconf worked but unfortunately "make" fails. It gives this error
> http://pastebin.ca/1791368 .

from the error log:
../../libust/.libs/libust.so: undefined reference to `rcu_init'

Seems that you don't have the urcu0.4.0 properly installed.

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

[Douglas Santos]

Quoting Naren <tracemein at gmail.com>:
> Autoconf worked but unfortunately "make" fails. It gives this error
> http://pastebin.ca/1791368 .

from the error log:
../../libust/.libs/libust.so: undefined reference to `rcu_init'

Seems that you don't have the urcu0.4.0 properly installed.

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

[Naren]

Hi ,

As Douglas mentioned, there were problems with rcu library installation. So
i uninstalled libkcopat, rcu and ust. Got the latest builds of libkcompat,
userspace-rcu and ust from git and installed them again in the above
mentioned order.

I am getting this error

*root at naren-laptop:/tmp# ustctl --list-markers 23444*
*ustctl[23462/23462]: Error: connect: No such file or directory (in
ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 23444*
*error while trying to list markers for PID 23444*
*root at naren-laptop:/tmp# *
*
*
I guess this is same error Soumya is getting.

Regards
Naren
*
*
*
*


On Tue, Feb 9, 2010 at 3:51 PM, Douglas Santos <douglas.santos at polymtl.ca>wrote:

> Quoting Naren <tracemein at gmail.com>:
> > Autoconf worked but unfortunately "make" fails. It gives this error
> > http://pastebin.ca/1791368 .
>
> from the error log:
> ../../libust/.libs/libust.so: undefined reference to `rcu_init'
>
> Seems that you don't have the urcu0.4.0 properly installed.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/ab819afb/attachment-0002.htm>

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

[Naren]

Hi ,

As Douglas mentioned, there were problems with rcu library installation. So
i uninstalled libkcopat, rcu and ust. Got the latest builds of libkcompat,
userspace-rcu and ust from git and installed them again in the above
mentioned order.

I am getting this error

*root at naren-laptop:/tmp# ustctl --list-markers 23444*
*ustctl[23462/23462]: Error: connect: No such file or directory (in
ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
*ustcmd_send_cmd: could not connect to PID 23444*
*error while trying to list markers for PID 23444*
*root at naren-laptop:/tmp# *
*
*
I guess this is same error Soumya is getting.

Regards
Naren
*
*
*
*


On Tue, Feb 9, 2010 at 3:51 PM, Douglas Santos <douglas.santos at polymtl.ca>wrote:

> Quoting Naren <tracemein at gmail.com>:
> > Autoconf worked but unfortunately "make" fails. It gives this error
> > http://pastebin.ca/1791368 .
>
> from the error log:
> ../../libust/.libs/libust.so: undefined reference to `rcu_init'
>
> Seems that you don't have the urcu0.4.0 properly installed.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/ab819afb/attachment-0003.htm>

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

[Pierre-Marc Fournier]

On February 9, 2010 11:43:24 Naren wrote:
> Hi ,
>
> As Douglas mentioned, there were problems with rcu library installation. So
> i uninstalled libkcopat, rcu and ust. Got the latest builds of libkcompat,
> userspace-rcu and ust from git and installed them again in the above
> mentioned order.
>
> I am getting this error
>
> *root at naren-laptop:/tmp# ustctl --list-markers 23444*
> *ustctl[23462/23462]: Error: connect: No such file or directory (in
> ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
> *ustcmd_send_cmd: could not connect to PID 23444*
> *error while trying to list markers for PID 23444*
> *root at naren-laptop:/tmp# *
> *
> *
> I guess this is same error Soumya is getting.
>

Looks like it. Please make sure:
- The program you are trying to trace still exists when you run ustctl
- The program you are trying to trace is linked to libust

Look in /tmp/ust-app-socks if a socket for this pid is created there when you 
start the program. If it's there, run ustctl in strace and send us the output 
near the connect() call so we can see what file it's trying to open.

I doubt this has something to do with permissions, as the error would not 
be "No such file or directory".

You might also want to configure ust with the command

CFLAGS="-DUST_DEBUG" ./configure

in order to enable additional debugging output.

pmf

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

[Pierre-Marc Fournier]

On February 8, 2010 20:48:16 soumyakanti chakraborty wrote:
> Hi Pierre
>
> I am still getting the same errors during the tracing of a particular
> process with specific pid's -
>
> *ustctl[1605/1605]: Error: connect: No such file or directory (in
> ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
> *ustcmd_send_cmd: could not connect to PID 1283*
> *error while trying to list markers for PID 1283*
>

Further thoughts on this. You could see this message also if libust is not 
linked to the program you are trying to trace.

Another case is if your program is registering a handler for SIGUSR1.

If not, send us the strace output around the connect() call.

pmf

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

[Naren]

Hi Pierre

I did a strace on ustctl as suggested by you. Found this problem with
connect call in strace.

*socket(PF_FILE, SOCK_STREAM, 0)         = 3*
*connect(3, {sa_family=AF_FILE, path="/tmp/ust-app-socks/11191"}, 110) = -1
ENOENT (No such file or directory)*
*gettid()                                = 23476*

I did a manual check on ust-app-socks, found only "ustd" running inside
that.

Regards,
Naren

On Tue, Feb 9, 2010 at 5:42 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> On February 8, 2010 20:48:16 soumyakanti chakraborty wrote:
> > Hi Pierre
> >
> > I am still getting the same errors during the tracing of a particular
> > process with specific pid's -
> >
> > *ustctl[1605/1605]: Error: connect: No such file or directory (in
> > ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
> > *ustcmd_send_cmd: could not connect to PID 1283*
> > *error while trying to list markers for PID 1283*
> >
>
> Further thoughts on this. You could see this message also if libust is not
> linked to the program you are trying to trace.
>
> Another case is if your program is registering a handler for SIGUSR1.
>
> If not, send us the strace output around the connect() call.
>
> pmf
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/b3920165/attachment-0003.htm>

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

[Naren]

Hi Pierre

I did a strace on ustctl as suggested by you. Found this problem with
connect call in strace.

*socket(PF_FILE, SOCK_STREAM, 0)         = 3*
*connect(3, {sa_family=AF_FILE, path="/tmp/ust-app-socks/11191"}, 110) = -1
ENOENT (No such file or directory)*
*gettid()                                = 23476*

I did a manual check on ust-app-socks, found only "ustd" running inside
that.

Regards,
Naren

On Tue, Feb 9, 2010 at 5:42 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> On February 8, 2010 20:48:16 soumyakanti chakraborty wrote:
> > Hi Pierre
> >
> > I am still getting the same errors during the tracing of a particular
> > process with specific pid's -
> >
> > *ustctl[1605/1605]: Error: connect: No such file or directory (in
> > ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
> > *ustcmd_send_cmd: could not connect to PID 1283*
> > *error while trying to list markers for PID 1283*
> >
>
> Further thoughts on this. You could see this message also if libust is not
> linked to the program you are trying to trace.
>
> Another case is if your program is registering a handler for SIGUSR1.
>
> If not, send us the strace output around the connect() call.
>
> pmf
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/b3920165/attachment-0002.htm>

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

[Pierre-Marc Fournier]

On February 9, 2010 12:11:33 Naren wrote:
> Hi Pierre
>
> I did a strace on ustctl as suggested by you. Found this problem with
> connect call in strace.
>
> *socket(PF_FILE, SOCK_STREAM, 0)         = 3*
> *connect(3, {sa_family=AF_FILE, path="/tmp/ust-app-socks/11191"}, 110) = -1
> ENOENT (No such file or directory)*
> *gettid()                                = 23476*
>
> I did a manual check on ust-app-socks, found only "ustd" running inside
> that.

Ok, good progress here.

Can you check that:
- the program you want to trace has been linked dynamically against libust. 
You can do so with the ldd tool.
- you did a "make install" when you upgraded your ust. You would get this 
error if ustctl and your traced program were linked against different 
versions of libust.so.
- there are no error messages in the console where your traced program is 
running.

>
> Regards,
> Naren
>
> On Tue, Feb 9, 2010 at 5:42 PM, Pierre-Marc Fournier <
>
> pierre-marc.fournier at polymtl.ca> wrote:
> > On February 8, 2010 20:48:16 soumyakanti chakraborty wrote:
> > > Hi Pierre
> > >
> > > I am still getting the same errors during the tracing of a particular
> > > process with specific pid's -
> > >
> > > *ustctl[1605/1605]: Error: connect: No such file or directory (in
> > > ustcomm_connect_path() at ../libustcomm/ustcomm.c:452)*
> > > *ustcmd_send_cmd: could not connect to PID 1283*
> > > *error while trying to list markers for PID 1283*
> >
> > Further thoughts on this. You could see this message also if libust is
> > not linked to the program you are trying to trace.
> >
> > Another case is if your program is registering a handler for SIGUSR1.
> >
> > If not, send us the strace output around the connect() call.
> >
> > pmf
> >
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

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

[Naren]

Hi Pierre,

>>- the program you want to trace has been linked dynamically against
libust.
>>You can do so with the ldd tool

The program i want to trace is firefox with pid 1684.

Here are the results of ldd'ing firefox

*root at naren-laptop:/tmp# ldd /usr/lib/firefox-3.5.7/firefox-3.5*
* **linux-gate.so.1 =>  (0xb7f27000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efc000)*
* **libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e35000)*
* **libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e30000)*
* **libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d3e000)*
* **libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d18000)*
* **libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cfa000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bb5000)*
* **/lib/ld-linux.so.2 (0xb7f28000)*
* **librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7bab000)*

Here are the results of ldd'ing ustctl

*root at naren-laptop:/tmp# ldd /usr/local/bin/ustctl *
* **linux-gate.so.1 =>  (0xb80ce000)*
* **liburcu-bp.so.0 => /usr/local/lib/liburcu-bp.so.0 (0xb80b8000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7f73000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f59000)*
* **/lib/ld-linux.so.2 (0xb80cf000)*
*
*
Here are the results of ldd'ing ustd (i am not sure whether it is helpful)

*root at naren-laptop:/tmp# ldd -v /usr/local/bin/ustd*
* **linux-gate.so.1 =>  (0xb7fe9000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7fbe000)*
* **liburcu-bp.so.0 => /usr/local/lib/liburcu-bp.so.0 (0xb7fba000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e74000)*
* **/lib/ld-linux.so.2 (0xb7fea000)*
*
*
* **Version information:*
* **/usr/local/bin/ustd:*
* **libc.so.6 (GLIBC_2.4) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.8) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.3.4) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **libpthread.so.0 (GLIBC_2.1) => /lib/tls/i686/cmov/libpthread.so.0*
* **libpthread.so.0 (GLIBC_2.3.3) => /lib/tls/i686/cmov/libpthread.so.0*
* **libpthread.so.0 (GLIBC_2.0) => /lib/tls/i686/cmov/libpthread.so.0*
* **/lib/tls/i686/cmov/libpthread.so.0:*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2*
* **libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.3.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_PRIVATE) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **/usr/local/lib/liburcu-bp.so.0:*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **libpthread.so.0 (GLIBC_2.0) => /lib/tls/i686/cmov/libpthread.so.0*
* **libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **/lib/tls/i686/cmov/libc.so.6:*
* **ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2*


>>you did a "make install" when you upgraded your ust. You would get this
>>error if ustctl and your traced program were linked against different
>>versions of libust.so

For what i infer, none of these are hooked up with libust. Have i missed out
any because i didn't even have the opportunity of starting a trace on
firefox, since i was not able to list markers.

*Moreover, another unrelated nitpick.*

In the manual http://lttng.org/files/ust/manual/ust.html, under section "5.2
Setting up the recording manually", the command  given to enable markers "$
ustctl --enable-marker 1234 ust/mymark" . However, after some reverse
engineering, i found out that "parse_opts_long" function "ustctl.c" file
expects pid to be the last argument and it is giving
"*ustctl[1813/1813]: Error: The pid "ust/1" is invalid. (in
parse_opts_long() at ustctl.c:159)*" error. Hence it would be "$ ustctl
--enable-marker ust/mymark 1234". I am not sure of this though. Can you
clarify?

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/94c1ec89/attachment-0003.htm>

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

[Naren]

Hi Pierre,

>>- the program you want to trace has been linked dynamically against
libust.
>>You can do so with the ldd tool

The program i want to trace is firefox with pid 1684.

Here are the results of ldd'ing firefox

*root at naren-laptop:/tmp# ldd /usr/lib/firefox-3.5.7/firefox-3.5*
* **linux-gate.so.1 =>  (0xb7f27000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efc000)*
* **libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e35000)*
* **libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e30000)*
* **libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d3e000)*
* **libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d18000)*
* **libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cfa000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bb5000)*
* **/lib/ld-linux.so.2 (0xb7f28000)*
* **librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7bab000)*

Here are the results of ldd'ing ustctl

*root at naren-laptop:/tmp# ldd /usr/local/bin/ustctl *
* **linux-gate.so.1 =>  (0xb80ce000)*
* **liburcu-bp.so.0 => /usr/local/lib/liburcu-bp.so.0 (0xb80b8000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7f73000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f59000)*
* **/lib/ld-linux.so.2 (0xb80cf000)*
*
*
Here are the results of ldd'ing ustd (i am not sure whether it is helpful)

*root at naren-laptop:/tmp# ldd -v /usr/local/bin/ustd*
* **linux-gate.so.1 =>  (0xb7fe9000)*
* **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7fbe000)*
* **liburcu-bp.so.0 => /usr/local/lib/liburcu-bp.so.0 (0xb7fba000)*
* **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e74000)*
* **/lib/ld-linux.so.2 (0xb7fea000)*
*
*
* **Version information:*
* **/usr/local/bin/ustd:*
* **libc.so.6 (GLIBC_2.4) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.8) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.3.4) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **libpthread.so.0 (GLIBC_2.1) => /lib/tls/i686/cmov/libpthread.so.0*
* **libpthread.so.0 (GLIBC_2.3.3) => /lib/tls/i686/cmov/libpthread.so.0*
* **libpthread.so.0 (GLIBC_2.0) => /lib/tls/i686/cmov/libpthread.so.0*
* **/lib/tls/i686/cmov/libpthread.so.0:*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2*
* **libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.3.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_PRIVATE) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **/usr/local/lib/liburcu-bp.so.0:*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **libpthread.so.0 (GLIBC_2.0) => /lib/tls/i686/cmov/libpthread.so.0*
* **libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6*
* **libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6*
* **/lib/tls/i686/cmov/libc.so.6:*
* **ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2*
* **ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2*


>>you did a "make install" when you upgraded your ust. You would get this
>>error if ustctl and your traced program were linked against different
>>versions of libust.so

For what i infer, none of these are hooked up with libust. Have i missed out
any because i didn't even have the opportunity of starting a trace on
firefox, since i was not able to list markers.

*Moreover, another unrelated nitpick.*

In the manual http://lttng.org/files/ust/manual/ust.html, under section "5.2
Setting up the recording manually", the command  given to enable markers "$
ustctl --enable-marker 1234 ust/mymark" . However, after some reverse
engineering, i found out that "parse_opts_long" function "ustctl.c" file
expects pid to be the last argument and it is giving
"*ustctl[1813/1813]: Error: The pid "ust/1" is invalid. (in
parse_opts_long() at ustctl.c:159)*" error. Hence it would be "$ ustctl
--enable-marker ust/mymark 1234". I am not sure of this though. Can you
clarify?

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100209/94c1ec89/attachment-0002.htm>

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

[Douglas Santos]

Quoting Naren <tracemein at gmail.com>:
> The program i want to trace is firefox with pid 1684.
>
> Here are the results of ldd'ing firefox
>
> *root at naren-laptop:/tmp# ldd /usr/lib/firefox-3.5.7/firefox-3.5*
> * **linux-gate.so.1 =>  (0xb7f27000)*
> * **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efc000)*
> * **libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e35000)*
> * **libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e30000)*
> * **libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d3e000)*
> * **libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d18000)*
> * **libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cfa000)*
> * **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bb5000)*
> * **/lib/ld-linux.so.2 (0xb7f28000)*
> * **librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7bab000)*

You need to instrument the code and link it with libust.
Which seems isn't the case here.
http://lttng.org/files/ust/manual/ust.html#Instrumenting-an-application

here's an ldd example of a instrumented and linked prog.
$ ldd ../test/mk
	linux-vdso.so.1 =>  (0x00007fff919ff000)
	libust.so.0 => /usr/local/lib/libust.so.0 (0x00007fe81031d000)
	libc.so.6 => /lib/libc.so.6 (0x00007fe80ffae000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe810542000)
	liburcu-bp.so.0 => /usr/local/lib/liburcu-bp.so.0 (0x00007fe80fdab000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe80fb8f000)


> In the manual http://lttng.org/files/ust/manual/ust.html, under section "5.2
> Setting up the recording manually", the command  given to enable markers "$
> ustctl --enable-marker 1234 ust/mymark" . However, after some reverse
> engineering, i found out that "parse_opts_long" function "ustctl.c" file
> expects pid to be the last argument and it is giving
> "*ustctl[1813/1813]: Error: The pid "ust/1" is invalid. (in
> parse_opts_long() at ustctl.c:159)*" error. Hence it would be "$ ustctl
> --enable-marker ust/mymark 1234". I am not sure of this though. Can you
> clarify?

The correct order is ustctl COMMAND PID

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

[Pierre-Marc Fournier]

On February 9, 2010 15:40:50 Naren wrote:
> Hi Pierre,
>
> >>- the program you want to trace has been linked dynamically against
>
> libust.
>
> >>You can do so with the ldd tool
>
> The program i want to trace is firefox with pid 1684.
>
> Here are the results of ldd'ing firefox
>
> *root at naren-laptop:/tmp# ldd /usr/lib/firefox-3.5.7/firefox-3.5*
> * **linux-gate.so.1 =>  (0xb7f27000)*
> * **libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efc000)*
> * **libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e35000)*
> * **libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e30000)*
> * **libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d3e000)*
> * **libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d18000)*
> * **libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cfa000)*
> * **libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bb5000)*
> * **/lib/ld-linux.so.2 (0xb7f28000)*
> * **librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7bab000)*

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

Without libust, the listener thread won't be created and the program will 
never create a socket in /tmp/ust-app-socks, hence your error message about 
the socket not being found.

Another way to do the LD_PRELOAD trick is to use usttrace, which will do it 
automatically with -l:

usttrace -l ./myprogram

Of course you need to add some instrumentation to firefox or to the libraries 
it's linked to, to see something interesting in the trace. Using the -m 
option to ustctl you can automatically instrument calls to malloc() and 
free() at the cost of an additional function call each time they are called.

Also note that firefox uses fork() and clone(). Because of this, you'll need 
to use libinterfork. This library intercepts calls to fork() and clone() and 
sets up the trace correctly in the new processes. You can use it with 
usttrace -f. This is a bit described in manual section "5.5 Tracing across 
fork() and clone()" (at http://lttng.org/files/ust/manual/ust.html) but it's 
still missing information... and it could probably use more testing.

>
> >>you did a "make install" when you upgraded your ust. You would get this
> >>error if ustctl and your traced program were linked against different
> >>versions of libust.so
>
> For what i infer, none of these are hooked up with libust. Have i missed
> out any because i didn't even have the opportunity of starting a trace on
> firefox, since i was not able to list markers.
>
> *Moreover, another unrelated nitpick.*
>
> In the manual http://lttng.org/files/ust/manual/ust.html, under section
> "5.2 Setting up the recording manually", the command  given to enable
> markers "$ ustctl --enable-marker 1234 ust/mymark" . However, after some
> reverse engineering, i found out that "parse_opts_long" function "ustctl.c"
> file expects pid to be the last argument and it is giving
> "*ustctl[1813/1813]: Error: The pid "ust/1" is invalid. (in
> parse_opts_long() at ustctl.c:159)*" error. Hence it would be "$ ustctl
> --enable-marker ust/mymark 1234". I am not sure of this though. Can you
> clarify?

You are absolutely right. It's now fixed. Thanks for reporting this!

pmf

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

[Naren]

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 .

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.*
*
*
*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?

Regards
Naren
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/ceb72a7e/attachment-0002.htm>

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

[Naren]

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 .

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.*
*
*
*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?

Regards
Naren
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/ceb72a7e/attachment-0001.htm>

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

[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

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

[Naren]

Hi Pierre

>>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.

As suggested, I did a back trace on ustctl. Prior to that, i did a clean
install and configured ust with flags on. Here is the stackdump produced by
bt.

*(gdb) bt full*
*#0  0x0804ddef in ustcmd_get_cmsf (cmsf=0xbffff35c, pid=5189)*
*    at ../libustcmd/ustcmd.c:284*
*        state = 49 '1'*
*        big_str = 0x8052018 "marker: metadata/core_marker_format 1
\"channel %s name %s format %s\" 0xb7ee3c6a\nmarker:
metadata/core_marker_format 1 \"channel %s name %s format %s\"
0xb7ee4bb0\nmarker: metadata/core_marker_id 1 \"chann"...*
*        result = 0*
*        tmp_cmsf = 0x8052408*
*        i = 135144*
*        cmsf_ind = 13*
*#1  0x08049cff in main (argc=3, argv=0xbffff534) at ustctl.c:267*
*        i = 0*
*        pidit = 0x8052008*
*        result = 0*
*        opts = {cmd = LIST_MARKERS, pids = 0x8052008, regex = 0x0}*
*        cmsf = 0x0*
*        __func__ = "main"*
*(gdb) *


Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/cfb05e6a/attachment-0002.htm>

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

[Naren]

Hi Pierre

>>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.

As suggested, I did a back trace on ustctl. Prior to that, i did a clean
install and configured ust with flags on. Here is the stackdump produced by
bt.

*(gdb) bt full*
*#0  0x0804ddef in ustcmd_get_cmsf (cmsf=0xbffff35c, pid=5189)*
*    at ../libustcmd/ustcmd.c:284*
*        state = 49 '1'*
*        big_str = 0x8052018 "marker: metadata/core_marker_format 1
\"channel %s name %s format %s\" 0xb7ee3c6a\nmarker:
metadata/core_marker_format 1 \"channel %s name %s format %s\"
0xb7ee4bb0\nmarker: metadata/core_marker_id 1 \"chann"...*
*        result = 0*
*        tmp_cmsf = 0x8052408*
*        i = 135144*
*        cmsf_ind = 13*
*#1  0x08049cff in main (argc=3, argv=0xbffff534) at ustctl.c:267*
*        i = 0*
*        pidit = 0x8052008*
*        result = 0*
*        opts = {cmd = LIST_MARKERS, pids = 0x8052008, regex = 0x0}*
*        cmsf = 0x0*
*        __func__ = "main"*
*(gdb) *


Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/cfb05e6a/attachment-0003.htm>

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

[Pierre-Marc Fournier]

On February 10, 2010 11:53:12 Naren wrote:
> Hi Pierre
>
> >>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.
>
> As suggested, I did a back trace on ustctl. Prior to that, i did a clean
> install and configured ust with flags on. Here is the stackdump produced by
> bt.
>
> *(gdb) bt full*
> *#0  0x0804ddef in ustcmd_get_cmsf (cmsf=0xbffff35c, pid=5189)*
> *    at ../libustcmd/ustcmd.c:284*
> *        state = 49 '1'*
> *        big_str = 0x8052018 "marker: metadata/core_marker_format 1
> \"channel %s name %s format %s\" 0xb7ee3c6a\nmarker:
> metadata/core_marker_format 1 \"channel %s name %s format %s\"
> 0xb7ee4bb0\nmarker: metadata/core_marker_id 1 \"chann"...*
> *        result = 0*
> *        tmp_cmsf = 0x8052408*
> *        i = 135144*
> *        cmsf_ind = 13*
> *#1  0x08049cff in main (argc=3, argv=0xbffff534) at ustctl.c:267*
> *        i = 0*
> *        pidit = 0x8052008*
> *        result = 0*
> *        opts = {cmd = LIST_MARKERS, pids = 0x8052008, regex = 0x0}*
> *        cmsf = 0x0*
> *        __func__ = "main"*
> *(gdb) *
>

I just commited a quick and dirty fix for this issue. A refactoring of the ust 
communication lib is in progress to address this more elegantly.

Thanks for the report!

pmf

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

[Naren]

Hi Pierre

>>I just commited a quick and dirty fix for this issue. A refactoring of the
ust
>>communication lib is in progress to address this more elegantly.

Everything is working fine.Finally. With the default markers,I am getting a
trace but in LTTV, i could only see the 6 events that was captured, hence
not getting anything in control flow viewer. I presume, lot many
instrumentations have to be added by me before i get to see any substantial
trace results.

Thanks a lot for you help.

However, i made few observations

1. In the terminal window, where i gave LD_PRELOAD, i am getting this error
after destroying the trace and closing the traced program

*root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
/usr/bin/gimp*
*libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
tracectl.c:632)*
*libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
tracectl.c:632)*
*
*
2. In the terminal window where ustd demon is running, i am getting the
following errors

*ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
pushed. This channel will not be usable passed this point. (in
consumer_loop() at ustd.c:399)*
*ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
put_subbuffer() at ustd.c:141)*
*ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0) (in
consumer_loop() at ustd.c:395)*
*ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
pushed. This channel will not be usable passed this point. (in
consumer_loop() at ustd.c:399)*
*
*
Buffer over error, is it due to the fact that trace is being recorded in
flight recorder mode?

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/cd4dd629/attachment-0003.htm>

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

[Naren]

Hi Pierre

>>I just commited a quick and dirty fix for this issue. A refactoring of the
ust
>>communication lib is in progress to address this more elegantly.

Everything is working fine.Finally. With the default markers,I am getting a
trace but in LTTV, i could only see the 6 events that was captured, hence
not getting anything in control flow viewer. I presume, lot many
instrumentations have to be added by me before i get to see any substantial
trace results.

Thanks a lot for you help.

However, i made few observations

1. In the terminal window, where i gave LD_PRELOAD, i am getting this error
after destroying the trace and closing the traced program

*root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
/usr/bin/gimp*
*libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
tracectl.c:632)*
*libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
tracectl.c:632)*
*
*
2. In the terminal window where ustd demon is running, i am getting the
following errors

*ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
pushed. This channel will not be usable passed this point. (in
consumer_loop() at ustd.c:399)*
*ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
put_subbuffer() at ustd.c:141)*
*ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0) (in
consumer_loop() at ustd.c:395)*
*ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
pushed. This channel will not be usable passed this point. (in
consumer_loop() at ustd.c:399)*
*
*
Buffer over error, is it due to the fact that trace is being recorded in
flight recorder mode?

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100210/cd4dd629/attachment-0002.htm>

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

[Pierre-Marc Fournier]

Hi Naren,

On February 10, 2010 17:08:21 Naren wrote:
> Hi Pierre
>
> >>I just commited a quick and dirty fix for this issue. A refactoring of
> >> the
>
> ust
>
> >>communication lib is in progress to address this more elegantly.
>
> Everything is working fine.Finally. With the default markers,I am getting a
> trace but in LTTV, i could only see the 6 events that was captured, hence
> not getting anything in control flow viewer. I presume, lot many
> instrumentations have to be added by me before i get to see any substantial
> trace results.

What you see is normal. In order to render the control flow view, lttv needs 
events that are generated by the kernel tracer. This includes events about 
scheduling, irq, syscalls etc. So the lttv control flow view in its current 
form is not useful with userspace traces.

You could load in lttv both a userspace trace and a kernel trace that was 
recorded at the same time. You would then get appropriate events for drawing 
the CFV as well as userspace events. For that you would need to make sure the 
TSC clock is used in ust (see kernelcompat.h).

For userspace tracing, as you say, you need to add your own instrumentation. 
This instrumentation will likely be specific to what your application does. 
However, libraries like libc could be instrumented and automatically events 
for all processes that use them. Interesting examples would be malloc/free 
instrumentation or instrumentation of the pthread locking api.

The control flow views could eventually be used to display 
application-specific information, for example session progress in a telecom 
application.

>
> Thanks a lot for you help.
>
> However, i made few observations
>
> 1. In the terminal window, where i gave LD_PRELOAD, i am getting this error
> after destroying the trace and closing the traced program
>
> *root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
> /usr/bin/gimp*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *
> *
> 2. In the terminal window where ustd demon is running, i am getting the
> following errors
>
> *ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
> put_subbuffer() at ustd.c:141)*
> *ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0)
> (in consumer_loop() at ustd.c:395)*
> *ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *
> *
> Buffer over error, is it due to the fact that trace is being recorded in
> flight recorder mode?

No. Flight recorder is not yet supported. There is no way to activate it.

Gimp is multi-process application, so you must use libinterfork.so. Did you 
LD_PRELOAD it?

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

[Naren]

Hi Pierre

>>No. Flight recorder is not yet supported. There is no way to activate it.
>>
>>Gimp is multi-process application, so you must use libinterfork.so. Did
you
>>LD_PRELOAD it?

Yes, I did LD_PRELOAD libust,libinterfork and libmallocwrap with Firefox not
with Gimp. I guess firefox,on startup, is not a multiprocess application in
the sense that it spawns only a single process. In contrasts, Gimp spawns
two processes.

Hence, LD_PRELOADing libust,libinterfork and libmallocwrap with Firefox
would not yield significant results. I will try the same with Gimp and get
back to you.

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100212/e4c9864f/attachment-0003.htm>

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

[Naren]

Hi Pierre

>>No. Flight recorder is not yet supported. There is no way to activate it.
>>
>>Gimp is multi-process application, so you must use libinterfork.so. Did
you
>>LD_PRELOAD it?

Yes, I did LD_PRELOAD libust,libinterfork and libmallocwrap with Firefox not
with Gimp. I guess firefox,on startup, is not a multiprocess application in
the sense that it spawns only a single process. In contrasts, Gimp spawns
two processes.

Hence, LD_PRELOADing libust,libinterfork and libmallocwrap with Firefox
would not yield significant results. I will try the same with Gimp and get
back to you.

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100212/e4c9864f/attachment-0002.htm>

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

[Pierre-Marc Fournier]

Naren <tracemein at gmail.com> a ??crit??:

> Hi Pierre
>
>>> I just commited a quick and dirty fix for this issue. A refactoring of the
> ust
>>> communication lib is in progress to address this more elegantly.
>
> Everything is working fine.Finally. With the default markers,I am getting a
> trace but in LTTV, i could only see the 6 events that was captured, hence
> not getting anything in control flow viewer. I presume, lot many
> instrumentations have to be added by me before i get to see any substantial
> trace results.
>
> Thanks a lot for you help.
>
> However, i made few observations
>
> 1. In the terminal window, where i gave LD_PRELOAD, i am getting this error
> after destroying the trace and closing the traced program
>
> *root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
> /usr/bin/gimp*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *
> *
> 2. In the terminal window where ustd demon is running, i am getting the
> following errors
>
> *ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
> put_subbuffer() at ustd.c:141)*
> *ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0) (in
> consumer_loop() at ustd.c:395)*
> *ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *
> *

Hi Naren,

A fix is upcoming for this issue. I will keep you posted.

Thanks for reporting.

pmf

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

[Naveh, Ido]

How the hell do I get off this mailing list???

-----Original Message-----
From: Pierre-Marc Fournier [mailto:pierre-marc.fournier@polymtl.ca] 
Sent: Monday, February 15, 2010 8:05 AM
To: Naren
Cc: ltt-dev at lists.casi.polymtl.ca
Subject: Re: [ltt-dev] UST - Problems in recording trace on a current process

Naren <tracemein at gmail.com> a ??crit??:

> Hi Pierre
>
>>> I just commited a quick and dirty fix for this issue. A refactoring of the
> ust
>>> communication lib is in progress to address this more elegantly.
>
> Everything is working fine.Finally. With the default markers,I am getting a
> trace but in LTTV, i could only see the 6 events that was captured, hence
> not getting anything in control flow viewer. I presume, lot many
> instrumentations have to be added by me before i get to see any substantial
> trace results.
>
> Thanks a lot for you help.
>
> However, i made few observations
>
> 1. In the terminal window, where i gave LD_PRELOAD, i am getting this error
> after destroying the trace and closing the traced program
>
> *root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
> /usr/bin/gimp*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer() at
> tracectl.c:632)*
> *
> *
> 2. In the terminal window where ustd demon is running, i am getting the
> following errors
>
> *ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
> put_subbuffer() at ustd.c:141)*
> *ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0) (in
> consumer_loop() at ustd.c:395)*
> *ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *
> *

Hi Naren,

A fix is upcoming for this issue. I will keep you posted.

Thanks for reporting.

pmf


_______________________________________________
ltt-dev mailing list
ltt-dev at lists.casi.polymtl.ca
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

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

[Mathieu Desnoyers]

* Naveh, Ido (Ido.Naveh at polycom.co.il) wrote:
> How the hell do I get off this mailing list???
> 
[...]
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

you login at the URL shown at the footer of every mailing list message
and follow the "unsubscribe from ltt-dev" instructions at the bottom of
the page.

I wish you a very nice day.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

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

[Naren]

Hi Pierre,

>>You could load in lttv both a userspace trace and a kernel trace that was
>>recorded at the same time. You would then get appropriate events for
drawing
>>the CFV as well as userspace events. For that you would need to make sure
the
>>TSC clock is used in ust (see kernelcompat.h).

I verified the clock source in kernelcompat.h. It uses gettimeofday from
sys/time.h. As you suggested, its imperative that a tsc clock source is used
when userspace and kernel tracing are combined.

I went through the timesource patch of lttng,x86-trace-clock.patch, a patch
dealing with switching clocksource of x86 architecture, to tsc.

Can you suggest as to how we can change the clocksource to tsc in ust?

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100215/a4a91dd8/attachment-0003.htm>

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

[Naren]

Hi Pierre,

>>You could load in lttv both a userspace trace and a kernel trace that was
>>recorded at the same time. You would then get appropriate events for
drawing
>>the CFV as well as userspace events. For that you would need to make sure
the
>>TSC clock is used in ust (see kernelcompat.h).

I verified the clock source in kernelcompat.h. It uses gettimeofday from
sys/time.h. As you suggested, its imperative that a tsc clock source is used
when userspace and kernel tracing are combined.

I went through the timesource patch of lttng,x86-trace-clock.patch, a patch
dealing with switching clocksource of x86 architecture, to tsc.

Can you suggest as to how we can change the clocksource to tsc in ust?

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100215/a4a91dd8/attachment-0002.htm>

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

[Pierre-Marc Fournier]

----- Original message -----
> Hi Pierre,
>
> > > You could load in lttv both a userspace trace and a kernel trace that was
> > > recorded at the same time. You would then get appropriate events for
> drawing
> > > the CFV as well as userspace events. For that you would need to make sure
> the
> > > TSC clock is used in ust (see kernelcompat.h).
>
> I verified the clock source in kernelcompat.h. It uses gettimeofday from
> sys/time.h. As you suggested, its imperative that a tsc clock source is used
> when userspace and kernel tracing are combined.
>
> I went through the timesource patch of lttng,x86-trace-clock.patch, a patch
> dealing with switching clocksource of x86 architecture, to tsc.
>
> Can you suggest as to how we can change the clocksource to tsc in ust?

Just replace the time source function in kernelcompat.h with the one that is commented and that contains asm code to read the tsc.

>
> Regards,
> Naren

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

[Pierre-Marc Fournier]

Naren wrote:
> Hi Pierre
> 
>>>I just commited a quick and dirty fix for this issue. A refactoring of
> the ust
>>>communication lib is in progress to address this more elegantly.
> 
> Everything is working fine.Finally. With the default markers,I am
> getting a trace but in LTTV, i could only see the 6 events that was
> captured, hence not getting anything in control flow viewer. I presume,
> lot many instrumentations have to be added by me before i get to see any
> substantial trace results. 
> 
> Thanks a lot for you help.
> 
> However, i made few observations
> 
> 1. In the terminal window, where i gave LD_PRELOAD, i am getting this
> error after destroying the trace and closing the traced program
> 
> *root at naren-laptop:/usr/src# LD_PRELOAD=/usr/local/lib/libust.so.0.0.0
> /usr/bin/gimp*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer()
> at tracectl.c:632)*
> *libust[9868/9869]: Error: cannot find trace! (in do_cmd_put_subbuffer()
> at tracectl.c:632)*
> *
> *
> 2. In the terminal window where ustd demon is running, i am getting the
> following errors
> 
> *ustd[9447/9820]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *ustd[9447/9881]: Error: unable to parse response to put_subbuffer (in
> put_subbuffer() at ustd.c:141)*
> *ustd[9447/9881]: Error: unknown error putting subbuffer (channel=ust_0)
> (in consumer_loop() at ustd.c:395)*
> *ustd[9447/9880]: Error: Buffer overflow (channel=metadata_0), reader
> pushed. This channel will not be usable passed this point. (in
> consumer_loop() at ustd.c:399)*
> *
> *
> Buffer over error, is it due to the fact that trace is being recorded in
> flight recorder mode?
> 

Hi Naren,

Please check if this is fixed in UST 0.2 that was just released.

Thanks!

pmf

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

[Naren]

Hi Pierre,

>>Hi Naren,
>>
>>Please check if this is fixed in UST 0.2 that was just released.
>>
>>Thanks!

Yes, i did a rerun of what i have done before. No, i am not getting the
errors. However, the errors are replaced by a few warnings. Thought i would
bring them to your attention.

*ustd[1501/2023]: Warning: For buffer ust_0, the trace was not found. This
likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*
*
*
*Since, i've tried UST on GIMP, could it be because of this. As GIMP spawns
two processes, of them, one is a python script and there is not much tracing
to be done in that. So could the buffer ust_0 correspond to that?*
*
*
*ustd[1501/2023]: Warning: application died while putting subbuffer (in
consumer_loop() at ustd.c:439)*
*ustd[1501/2022]: Warning: For buffer metadata_0, the trace was not found.
This likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*

When i tried to view the two traces, i am successful in viewing the 2nd
trace, and for the first trace (i guess, it corresponds to Gimp python
scripts), i am getting the" Cannot open trace : maybe you should enter in
the trace directory to select it ?" message.

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100218/b0d0858b/attachment.htm>

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

[Naren]

Hi Pierre,

>>Hi Naren,
>>
>>Please check if this is fixed in UST 0.2 that was just released.
>>
>>Thanks!

Yes, i did a rerun of what i have done before. No, i am not getting the
errors. However, the errors are replaced by a few warnings. Thought i would
bring them to your attention.

*ustd[1501/2023]: Warning: For buffer ust_0, the trace was not found. This
likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*
*
*
*Since, i've tried UST on GIMP, could it be because of this. As GIMP spawns
two processes, of them, one is a python script and there is not much tracing
to be done in that. So could the buffer ust_0 correspond to that?*
*
*
*ustd[1501/2023]: Warning: application died while putting subbuffer (in
consumer_loop() at ustd.c:439)*
*ustd[1501/2022]: Warning: For buffer metadata_0, the trace was not found.
This likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*

When i tried to view the two traces, i am successful in viewing the 2nd
trace, and for the first trace (i guess, it corresponds to Gimp python
scripts), i am getting the" Cannot open trace : maybe you should enter in
the trace directory to select it ?" message.

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100218/b0d0858b/attachment-0001.htm>

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

[Naren]

Hi Pierre,

>>Hi Naren,
>>
>>Please check if this is fixed in UST 0.2 that was just released.
>>
>>Thanks!

Yes, i did a rerun of what i have done before. No, i am not getting the
errors. However, the errors are replaced by a few warnings. Thought i would
bring them to your attention.

*ustd[1501/2023]: Warning: For buffer ust_0, the trace was not found. This
likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*
*
*
*Since, i've tried UST on GIMP, could it be because of this. As GIMP spawns
two processes, of them, one is a python script and there is not much tracing
to be done in that. So could the buffer ust_0 correspond to that?*
*
*
*ustd[1501/2023]: Warning: application died while putting subbuffer (in
consumer_loop() at ustd.c:439)*
*ustd[1501/2022]: Warning: For buffer metadata_0, the trace was not found.
This likely means it was destroyed by the user. (in put_subbuffer() at
ustd.c:164)*

When i tried to view the two traces, i am successful in viewing the 2nd
trace, and for the first trace (i guess, it corresponds to Gimp python
scripts), i am getting the" Cannot open trace : maybe you should enter in
the trace directory to select it ?" message.

Regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100218/b0d0858b/attachment-0002.htm>

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

[Pierre-Marc Fournier]

Naren wrote:
> Hi Pierre,
> 
>>>Hi Naren,
>>>
>>>Please check if this is fixed in UST 0.2 that was just released.
>>>
>>>Thanks!
> 
> Yes, i did a rerun of what i have done before. No, i am not getting the
> errors. However, the errors are replaced by a few warnings. Thought i
> would bring them to your attention.
> 
> *ustd[1501/2023]: Warning: For buffer ust_0, the trace was not found.
> This likely means it was destroyed by the user. (in put_subbuffer() at
> ustd.c:164)*
> *
> *
> /Since, i've tried UST on GIMP, could it be because of this. As GIMP
> spawns two processes, of them, one is a python script and there is not
> much tracing to be done in that. So could the buffer ust_0 correspond to
> that?/
> */
> /*
> *ustd[1501/2023]: Warning: application died while putting subbuffer (in
> consumer_loop() at ustd.c:439)*
> *ustd[1501/2022]: Warning: For buffer metadata_0, the trace was not
> found. This likely means it was destroyed by the user. (in
> put_subbuffer() at ustd.c:164)*

These warnings are ok. They just mean that the application terminated
before the trace was cleanly destroyed, and that the daemon will do
crash recovery on them.

I am still trying to find the right balance between printing information
and not scaring the user. Now that you ask about them, I realize these
messages should probably not be warnings. I will move them to DBG()
messages which are printed only when debug output is activated.

> 
> When i tried to view the two traces, i am successful in viewing the 2nd
> trace, and for the first trace (i guess, it corresponds to Gimp python
> scripts), i am getting the" Cannot open trace : maybe you should enter
> in the trace directory to select it ?" message.

What do you see in the trace directory (the one that doesn't work)? What
files and are they zero size or do they contain something?

> 
> Regards,
> Naren
> 

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

[Naren]

Hi Pierre,

>>What do you see in the trace directory (the one that doesn't work)? What
>>files and are they zero size or do they contain something?

Yes, they are of zero size. Its actually zero byte.

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100219/c6172a65/attachment-0003.htm>

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

[Naren]

Hi Pierre,

>>What do you see in the trace directory (the one that doesn't work)? What
>>files and are they zero size or do they contain something?

Yes, they are of zero size. Its actually zero byte.

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100219/c6172a65/attachment-0002.htm>

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

[Naren]

Hi Pierre,

>>What do you see in the trace directory (the one that doesn't work)? What
>>files and are they zero size or do they contain something?

Yes, they are of zero size. Its actually zero byte.

Regards
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100219/c6172a65/attachment.htm>

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

[soumyakanti chakraborty]

> Hi Pierre,
>
> >>>What do you see in the trace directory (the one that doesn't work)? What
> >>>files and are they zero size or do they contain something?
>
> Yes, they are of zero size. Its actually zero byte.
>

Hi Pierre,

I did a manual trace with Firefox and received the following errors pasted
in the below link -

http://pastebin.ca/1805238

Like Naren, I also received some directories which has no traces inside
/tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to know
if the above errors has something to do with no significant results getting
displayed in lttv during batch analysis.

Regards,
Soumya

>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100222/3edaeeb0/attachment.htm>

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

[soumyakanti chakraborty]

> Hi Pierre,
>
> >>>What do you see in the trace directory (the one that doesn't work)? What
> >>>files and are they zero size or do they contain something?
>
> Yes, they are of zero size. Its actually zero byte.
>

Hi Pierre,

I did a manual trace with Firefox and received the following errors pasted
in the below link -

http://pastebin.ca/1805238

Like Naren, I also received some directories which has no traces inside
/tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to know
if the above errors has something to do with no significant results getting
displayed in lttv during batch analysis.

Regards,
Soumya

>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100222/3edaeeb0/attachment-0001.htm>

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

[soumyakanti chakraborty]

> Hi Pierre,
>
> >>>What do you see in the trace directory (the one that doesn't work)? What
> >>>files and are they zero size or do they contain something?
>
> Yes, they are of zero size. Its actually zero byte.
>

Hi Pierre,

I did a manual trace with Firefox and received the following errors pasted
in the below link -

http://pastebin.ca/1805238

Like Naren, I also received some directories which has no traces inside
/tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to know
if the above errors has something to do with no significant results getting
displayed in lttv during batch analysis.

Regards,
Soumya

>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100222/3edaeeb0/attachment-0002.htm>

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

[Pierre-Marc Fournier]

soumyakanti chakraborty wrote:
> 
>     Hi Pierre,
> 
>     >>>What do you see in the trace directory (the one that doesn't
>     work)? What
>     >>>files and are they zero size or do they contain something?
> 
>     Yes, they are of zero size. Its actually zero byte.
> 
> 
> Hi Pierre, 
> 
> I did a manual trace with Firefox and received the following errors
> pasted in the below link - 
> 
> http://pastebin.ca/1805238

There are some remaining issues with tracing of multi-process
applications. Firefox, because of its complexity, is a very good torture
test. I will dig into this this week. Thanks for the feedback.

> 
> Like Naren, I also received some directories which has no traces inside
> /tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to
> know if the above errors has something to do with no significant results
> getting displayed in lttv during batch analysis.

Not sure if I understand what you mean. Batch analysis is the framework
on which the lttv textdump plugin is based. Do you mean you get nothing
in text dump? Or in your own custom plugin based on batch analysis.

Normally you should at least get events for tracefiles that have
non-zero size.

>  
> Regards,
> Soumya
> 
> 
> 
> 

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

[soumyakanti chakraborty]

On Tue, Feb 23, 2010 at 4:15 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> soumyakanti chakraborty wrote:
> >
> >     Hi Pierre,
> >
> >     >>>What do you see in the trace directory (the one that doesn't
> >     work)? What
> >     >>>files and are they zero size or do they contain something?
> >
> >     Yes, they are of zero size. Its actually zero byte.
> >
> >
> > Hi Pierre,
> >
> > I did a manual trace with Firefox and received the following errors
> > pasted in the below link -
> >
> > http://pastebin.ca/1805238
>
> There are some remaining issues with tracing of multi-process
> applications. Firefox, because of its complexity, is a very good torture
> test. I will dig into this this week. Thanks for the feedback.
>

Thanks for that, I think that will help.

>
> >
> > Like Naren, I also received some directories which has no traces inside
> > /tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to
> > know if the above errors has something to do with no significant results
> > getting displayed in lttv during batch analysis.
>
> Not sure if I understand what you mean. Batch analysis is the framework
> on which the lttv textdump plugin is based. Do you mean you get nothing
> in text dump? Or in your own custom plugin based on batch analysis.
>
> Normally you should at least get events for tracefiles that have
> non-zero size.
>

Yup, we are getting events for tracefiles which are non-zero in size. I was
mentioning that if a application spawn 5 other processes, in some of the pid
folders we are getting a 0 byte metadata_0 file, which I think is absolutely
fine as those parts didn't do any sorts of work (Like the python extension
scripts of GIMP).

Just another thing bit different from the above discussion, I just
downloaded UST from the git and tried to install but during "make" it
shooted the following error given below -

*libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include
-I../libustcomm -DUST_COMPONENT=ust_snprintf -fPIC -g -O2 -MT
libustsnprintf_la-snprintf.lo -MD -MP -MF
.deps/libustsnprintf_la-snprintf.Tpo -c snprintf.c  -fPIC -DPIC -o
.libs/libustsnprintf_la-snprintf.o
snprintf.c:39:26: error: ust_snprintf.h: No such file or directory
make[2]: *** [libustsnprintf_la-snprintf.lo] Error 1
make[2]: Leaving directory `/usr/src/ust/snprintf'

*There was a update in git "*use signal safe ust_safe_snprintf()* " .. 6
days back in which the commitdiff shows that +noinst_HEADERS = share.h
usterr.h ust_snprintf.h getting added in the *Makefile.am. *Could this be
the reason for getting the above error during installation ?

Regards,
Soumya



> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100226/4d3b93ca/attachment.htm>

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

[soumyakanti chakraborty]

On Tue, Feb 23, 2010 at 4:15 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> soumyakanti chakraborty wrote:
> >
> >     Hi Pierre,
> >
> >     >>>What do you see in the trace directory (the one that doesn't
> >     work)? What
> >     >>>files and are they zero size or do they contain something?
> >
> >     Yes, they are of zero size. Its actually zero byte.
> >
> >
> > Hi Pierre,
> >
> > I did a manual trace with Firefox and received the following errors
> > pasted in the below link -
> >
> > http://pastebin.ca/1805238
>
> There are some remaining issues with tracing of multi-process
> applications. Firefox, because of its complexity, is a very good torture
> test. I will dig into this this week. Thanks for the feedback.
>

Thanks for that, I think that will help.

>
> >
> > Like Naren, I also received some directories which has no traces inside
> > /tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to
> > know if the above errors has something to do with no significant results
> > getting displayed in lttv during batch analysis.
>
> Not sure if I understand what you mean. Batch analysis is the framework
> on which the lttv textdump plugin is based. Do you mean you get nothing
> in text dump? Or in your own custom plugin based on batch analysis.
>
> Normally you should at least get events for tracefiles that have
> non-zero size.
>

Yup, we are getting events for tracefiles which are non-zero in size. I was
mentioning that if a application spawn 5 other processes, in some of the pid
folders we are getting a 0 byte metadata_0 file, which I think is absolutely
fine as those parts didn't do any sorts of work (Like the python extension
scripts of GIMP).

Just another thing bit different from the above discussion, I just
downloaded UST from the git and tried to install but during "make" it
shooted the following error given below -

*libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include
-I../libustcomm -DUST_COMPONENT=ust_snprintf -fPIC -g -O2 -MT
libustsnprintf_la-snprintf.lo -MD -MP -MF
.deps/libustsnprintf_la-snprintf.Tpo -c snprintf.c  -fPIC -DPIC -o
.libs/libustsnprintf_la-snprintf.o
snprintf.c:39:26: error: ust_snprintf.h: No such file or directory
make[2]: *** [libustsnprintf_la-snprintf.lo] Error 1
make[2]: Leaving directory `/usr/src/ust/snprintf'

*There was a update in git "*use signal safe ust_safe_snprintf()* " .. 6
days back in which the commitdiff shows that +noinst_HEADERS = share.h
usterr.h ust_snprintf.h getting added in the *Makefile.am. *Could this be
the reason for getting the above error during installation ?

Regards,
Soumya



> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100226/4d3b93ca/attachment-0002.htm>

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

[soumyakanti chakraborty]

On Tue, Feb 23, 2010 at 4:15 PM, Pierre-Marc Fournier <
pierre-marc.fournier at polymtl.ca> wrote:

> soumyakanti chakraborty wrote:
> >
> >     Hi Pierre,
> >
> >     >>>What do you see in the trace directory (the one that doesn't
> >     work)? What
> >     >>>files and are they zero size or do they contain something?
> >
> >     Yes, they are of zero size. Its actually zero byte.
> >
> >
> > Hi Pierre,
> >
> > I did a manual trace with Firefox and received the following errors
> > pasted in the below link -
> >
> > http://pastebin.ca/1805238
>
> There are some remaining issues with tracing of multi-process
> applications. Firefox, because of its complexity, is a very good torture
> test. I will dig into this this week. Thanks for the feedback.
>

Thanks for that, I think that will help.

>
> >
> > Like Naren, I also received some directories which has no traces inside
> > /tmp/usttrace, those directories had a 0 byte metadata_0 file. Just to
> > know if the above errors has something to do with no significant results
> > getting displayed in lttv during batch analysis.
>
> Not sure if I understand what you mean. Batch analysis is the framework
> on which the lttv textdump plugin is based. Do you mean you get nothing
> in text dump? Or in your own custom plugin based on batch analysis.
>
> Normally you should at least get events for tracefiles that have
> non-zero size.
>

Yup, we are getting events for tracefiles which are non-zero in size. I was
mentioning that if a application spawn 5 other processes, in some of the pid
folders we are getting a 0 byte metadata_0 file, which I think is absolutely
fine as those parts didn't do any sorts of work (Like the python extension
scripts of GIMP).

Just another thing bit different from the above discussion, I just
downloaded UST from the git and tried to install but during "make" it
shooted the following error given below -

*libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include
-I../libustcomm -DUST_COMPONENT=ust_snprintf -fPIC -g -O2 -MT
libustsnprintf_la-snprintf.lo -MD -MP -MF
.deps/libustsnprintf_la-snprintf.Tpo -c snprintf.c  -fPIC -DPIC -o
.libs/libustsnprintf_la-snprintf.o
snprintf.c:39:26: error: ust_snprintf.h: No such file or directory
make[2]: *** [libustsnprintf_la-snprintf.lo] Error 1
make[2]: Leaving directory `/usr/src/ust/snprintf'

*There was a update in git "*use signal safe ust_safe_snprintf()* " .. 6
days back in which the commitdiff shows that +noinst_HEADERS = share.h
usterr.h ust_snprintf.h getting added in the *Makefile.am. *Could this be
the reason for getting the above error during installation ?

Regards,
Soumya



> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100226/4d3b93ca/attachment-0001.htm>

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

[Pierre-Marc Fournier]

soumyakanti chakraborty wrote:
>  
> /There was a update in git "*use signal safe ust_safe_snprintf()* " .. 6
> days back in which the commitdiff shows that +noinst_HEADERS = share.h
> usterr.h ust_snprintf.h getting added in the *Makefile.am. *Could this
> be the reason for getting the above error during installation ?

Just pushed ust_snprintf.h, which was forgotten. Thanks for testing!

pmf

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

[Douglas Santos]

Quoting Naren <tracemein at gmail.com>:
> When executing ustctl in manual mode to record a trace on a current process,
> i am getting the following error.
>
> *Error: connect: No such file or directory (../libustcomm/ustcomm.c:452)*
> *ustcmd_send_cmd: could not connect to PID 1989*
> *error while trying to list markers for PID 1989*

I'm supposing that you are using the latest git version with rcu0.4.0.

The error "could not connect to PID 1989" maybe related to the permissions.
Like you started ustd as root and ustctl as an unprivileged user.