[ltt-dev] ltt channel thread safe?

[chris.meyers.fsu@gmail.com (chris meyers)]

Forget any mention of threading being the reason.  After trying way too many
things, removal of the __FUNCTION__ macro seems to "fix" the problem.  Does
the  __FUNCTION__ macro not play well with ltt?  The binary trace file
seemed void of any error.  It seemed as if the __FUNCTION__ macro had some
indirect influence on how the lttv -m textDump behaved.

-Chris

On Wed, Aug 4, 2010 at 2:12 AM, chris meyers <chris.meyers.fsu at gmail.com>wrote:

> To give a bit of context to the problem.  I am using user space ltt to help
> profile code.  I have created two events, time_begin and time_end.  The goal
> is to allow for logging the runtime of specific code blocks via start()
> stop() insertions.
>
> I am having some issues with traces not coming out "correct" on the other
> "end".  Let me further explain what I mean by correct and end.
>
> correct
> trace_mark(ust, time_begin, "thread %d func %s depth %d extra %s", 0,
> __FUNCTION__, 1, __FUNCTION__)
> trace_mark(ust, time_end, "thread %d func %s depth %d extra %s", 0,
> __FUNCTION__, 1, __FUNCTION__)
>
> end
> ust.time_begin: 30208.932264102
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func =
> "memloc_request_response_decider", depth = 1, extra =
> "memloc_request_response_decider" }
> ust.time_end: 30208.932267455
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func =
> "memloc_request_response_decider", depth = 1, extra =
> "memloc_request_response_decider" }
>
> Later on the output looks like this:
> ust.time_begin: 30198.142843837
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func = "ne_worker_thread",
> depth = 560296821, extra = "" }
>
> Notice that in the trace_mark() code above I hard coded depth to be 0 and
> _str is always __FUNCTION__.
>
> Possible reasons:
> * Buffer is being overrun.  I changed the buffer size using the -N and -S
> options in usttrace to something > 2 MB (plenty large).
> * Channels are not thread-safe?  I have 3 threads of execution in this
> example.  All using the ust channel.
> * My code is crappy and I am overwriting the lust library buffer?
>
>
> Also, I am having trouble using any channel other than ust.  Is ust the
> only channel available in user space?
>
> Many thanks,
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100806/5aa70a13/attachment.htm>