All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Rajotte Julien <Jonathan.rajotte-julien@efficios.com>
To: Christian Ascheberg <caschebe@techfak.uni-bielefeld.de>
Cc: lttng-dev@lists.lttng.org
Subject: Re: Problem LD_PRELOADing multiple UST helpers
Date: Wed, 21 Oct 2015 11:38:11 -0400	[thread overview]
Message-ID: <5627B163.5060407__38769.1797259778$1445441981$gmane$org@efficios.com> (raw)
In-Reply-To: <5627922E.9000808@techfak.uni-bielefeld.de>

Hi Christian,

The more debug output the merrier !

Could you attach the file generated (ld_debug.out.xxxx) by this command:

LD_PRELOAD="liblttng-ust-libc-wrapper.so liblttng-ust-cyg-profile.so 
liblttng-ust-pthread-wrapper.so liblttng-ust-dl.so" LD_DEBUG=all 
LD_DEBUG_OUTPUT=ld_debug.out ls

Also is the output provided in your previous email all of the debug 
output from 'ls' ?

Cheers!

On 2015-10-21 09:25 AM, Christian Ascheberg wrote:
> Hello,
>
> I am having a strange problem with LTTng UST helpers on a Cyclone V 
> ARM development board. If I LD_PRELOAD multiple helpers, then only 
> data of the first loaded helper appears in the trace.
> Below I have some debug output that looks wrong:
>
> This is the command:
> root@cyclone5:~# LTTNG_UST_DEBUG=1 
> LD_PRELOAD="liblttng-ust-libc-wrapper.so liblttng-ust-cyg-profile.so 
> liblttng-ust-pthread-wrapper.so liblttng-ust-dl.so" ls
>
> - This is some output regarding the first registration:
> liblttng_ust_tracepoint[XXX/XXX]: just registered a tracepoints 
> section from 0x76e7b42c and having 2 tracepoints (in 
> tracepoint_register_lib() at tracepoint.c:767)
> liblttng_ust_tracepoint[XXX/XXX]: registered tracepoint: 
> ust_baddr_statedump:soinfo (in tracepoint_register_lib() at 
> tracepoint.c:772)
> liblttng_ust_tracepoint[XXX/XXX]: registered tracepoint: 
> lttng_ust_tracef:event (in tracepoint_register_lib() at tracepoint.c:772)
> libust[XXX/XXX]: Provider "ust_baddr_statedump" accepted, version 1.0 
> is compatible with LTTng UST provider version 1.0. (in 
> check_provider_version() at lttng-probes.c:174)
> libust[XXX/XXX]: adding probe ust_baddr_statedump containing 1 events 
> to lazy registration list (in lttng_probe_register() at 
> lttng-probes.c:216)
> libust[XXX/XXY]: just registered probe ust_baddr_statedump containing 
> 1 events (in lttng_lazy_probe_register() at lttng-probes.c:115)
> libust[XXX/XXY]: Sent register event notification for name 
> "ust_baddr_statedump:soinfo": ret_code 0, event_id 0
>  (in ustcomm_register_event() at lttng-ust-comm.c:1001)
> liblttng_ust_tracepoint[XXX/XXY]: Registering probe to tracepoint 
> ust_baddr_statedump:soinfo (in __tracepoint_probe_register() at 
> tracepoint.c:563)
> liblttng_ust_tracepoint[XXX/XXX]: Registering probe to tracepoint 
> lttng_ust_tracef:event (in __tracepoint_probe_register() at 
> tracepoint.c:563)
>
> - And here is some strange output regarding another registration:
> liblttng_ust_tracepoint[XXX/XXX]: just registered a tracepoints 
> section from 0x76e7b42c and having 2 tracepoints (in 
> tracepoint_register_lib() at tracepoint.c:767)
> liblttng_ust_tracepoint[XXX/XXX]: registered tracepoint: 
> ust_baddr_statedump:soinfo (in tracepoint_register_lib() at 
> tracepoint.c:772)
> liblttng_ust_tracepoint[XXX/XXX]: registered tracepoint: 
> lttng_ust_tracef:event (in tracepoint_register_lib() at tracepoint.c:772)
> libust[XXX/XXX]: Provider "ust_pthread" accepted, version 1.0 is 
> compatible with LTTng UST provider version 1.0. (in 
> check_provider_version() at lttng-probes.c:174)
> libust[XXX/XXX]: adding probe ust_pthread containing 4 events to lazy 
> registration list (in lttng_probe_register() at lttng-probes.c:216)
> libust[XXX/XXX]: just registered probe ust_pthread containing 4 events 
> (in lttng_lazy_probe_register() at lttng-probes.c:115)
> libust[XXX/XXX]: Sent register event notification for name 
> "ust_pthread:pthread_mutex_lock_req": ret_code 0, event_id 4
>  (in ustcomm_register_event() at lttng-ust-comm.c:1001)
> libust[XXX/XXX]: Sent register event notification for name 
> "ust_pthread:pthread_mutex_lock_acq": ret_code 0, event_id 5
>  (in ustcomm_register_event() at lttng-ust-comm.c:1001)
> libust[XXX/XXX]: Sent register event notification for name 
> "ust_pthread:pthread_mutex_trylock": ret_code 0, event_id 6
>  (in ustcomm_register_event() at lttng-ust-comm.c:1001)
> libust[XXX/XXX]: Sent register event notification for name 
> "ust_pthread:pthread_mutex_unlock": ret_code 0, event_id 7
>  (in ustcomm_register_event() at lttng-ust-comm.c:1001)
> liblttng_ust_tracepoint[XXX/XXX]: Registering probe to tracepoint 
> ust_pthread:pthread_mutex_unlock (in __tracepoint_probe_register() at 
> tracepoint.c:563)
> liblttng_ust_tracepoint[XXX/XXX]: Registering probe to tracepoint 
> ust_pthread:pthread_mutex_trylock (in __tracepoint_probe_register() at 
> tracepoint.c:563)
> liblttng_ust_tracepoint[XXX/XXX]: Registering probe to tracepoint 
> ust_pthread:pthread_mutex_lock_acq (in __tracepoint_probe_register() 
> at tracepoint.c:563)
> liblttng_ust_tracepoint[XXX/XXX]: Registering probe to tracepoint 
> ust_pthread:pthread_mutex_lock_req (in __tracepoint_probe_register() 
> at tracepoint.c:563)
>
> As with this one, the first three lines of all registrations are 
> always the same and do not match the following (in this case) 
> 'Provider "ust_pthread" accepted'.
> I subsequently only get tracepoint data from ust_baddr_statedump:soinfo.
>
> I followed these build instructions for my board using Yocto 1.7: 
> http://rocketboards.org/foswiki/view/Documentation/GSRD150CompilingLinux
> I also tried updating the recipes to use the latest version of LTTng. 
> The output above is from LTTng v2.6.2.
> I can provide more debug output if that helps. I do not see this 
> problem on my desktop computer.
>
> Can somebody confirm this problem?
>
> Thanks, Christian
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Jonathan R. Julien
Efficios

       reply	other threads:[~2015-10-21 15:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5627922E.9000808@techfak.uni-bielefeld.de>
2015-10-21 15:38 ` Jonathan Rajotte Julien [this message]
     [not found] ` <5627B163.5060407@efficios.com>
2015-10-23 17:09   ` Problem LD_PRELOADing multiple UST helpers Christian Ascheberg
2015-10-21 13:25 Christian Ascheberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='5627B163.5060407__38769.1797259778$1445441981$gmane$org@efficios.com' \
    --to=jonathan.rajotte-julien@efficios.com \
    --cc=caschebe@techfak.uni-bielefeld.de \
    --cc=lttng-dev@lists.lttng.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.