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

[pierre-marc.fournier@polymtl.ca (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
>