Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: jpaul@gdrs.com (jpaul@gdrs.com)
Subject: [ltt-dev] LTT UserSpace Tracer, broken?
Date: Thu, 20 May 2010 17:50:46 -0400	[thread overview]
Message-ID: <A47866F933DF804684068A24BF04A9730862A838@gdrs-exchange.gdrs.com> (raw)
In-Reply-To: <20100520140350.GB9108@Krystal>

So, I'm switching modes and attempting to get the "user space tracer" up and running. I'm following the instructions provided here:

http://lttng.org/files/ust/manual/ust.html

I've downloaded and built the following packages:

    libkcompat-0.2.tar.gz
    ust-0.4.tar.gz
    userspace-rcu-0.4.3.tar.bz2
    lttv-0.12.31-04072010.tar.gz

First issue: ust-0.4 will not compile due to an undefined reference to sched_getcpu(). I'm using the latest version of Redhat Enterprise 5.5 and my installed glibc doesn't have that method defined (gcc version=4.3.4, glibc version=2.5-49 .. believe this method came into being around glibc-2.6?). Knowing that upgrading glibc is not a trivial process (as I've actually taken down a machine by doing so incorrectly), I'm not confident that most users may not want to go that route. I've downloaded glib2-2.11 and pulled some code out of that library to place the following in serialize.c:

// Added to avoid upgrading glibc
int
sched_getcpu (void)
{
#ifdef __NR_getcpu
  unsigned int cpu;
//  int r = INLINE_SYSCALL (getcpu, 3, &cpu, NULL, NULL);
  int r = syscall(SYS_getcpu, 3, &cpu, NULL, NULL);

  return r == -1 ? r : cpu;
#else
  __set_errno (ENOSYS);
  return -1;
#endif
}

That may or may not be the cause of some follow-on issues. Maybe glibc "really" needs to be upgraded to effectively use the userspace tracer .. please comment if so and I go that route next. Also, note that I'm doing all this work at "root", so there should be no permissions issues.

Next, I attempted to build and run the "quick start" code as detailed in the instructions (copying that code into ustTest.c):

gcc -o ustTest -g -Wall ustTest.c -lust

# usttrace ./ustTest
/usr/local/bin/usttrace: line 156: 23606 Segmentation fault      $CMD 2>&1
Waiting for ustd to shutdown...
Trace was output in:  /root/.usttraces/machineName-20100520172047665580280

# lttv -m textDump -t  /root/.usttraces/machineName-20100520172047665580280
** (process:23613): WARNING **: Trace /root/.usttraces/machineName-20100520172047665580280 has no metadata tracefile
** (process:23613): CRITICAL **: cannot open trace /root/.usttraces/machineName-20100520172047665580280
/usr/local/bin/lttv: line 15: 23613 Segmentation fault      $0.real $*

So, next I gave up on the command line attempts and tried to get things up and running manually (still using the provided instructions).

mkdir /tmp/ustsocks   <- not sure this is correct anymore, may have changed to: /tmp/ust-app-socks
mkdir /tmp/trace
ustd &
./ustTest &
[7] 23652

My ustTest was changed as follows before running that executable:

int main(int argc, char **argv)
{
    int v = 23;
    char *st = "test23";

    for(;;)
    {
    trace_mark(main, 23, "firstarg %d secondarg %s", v, st);

    /* another marker without arguments: */
    trace_mark(main, 24, MARK_NOARGS);
    sleep(30);
    }

    return 0;
}

# ustctl --list-markers 23652
{PID: 23652, channel/marker: metadata/core_marker_id, state: 1, fmt: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u" 0x3301d0}
{PID: 23652, channel/marker: metadata/core_marker_format, state: 1, fmt: "channel %s name %s format %s" 0x3301e3}
{PID: 23652, channel/marker: metadata/core_marker_format, state: 1, fmt: "channel %s name %s format %s" 0x330d63}
{PID: 23652, channel/marker: metadata/core_marker_id, state: 1, fmt: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u" 0x331483}
{PID: 23652, channel/marker: metadata/core_marker_format, state: 1, fmt: "channel %s name %s format %s" 0x332b35}
{PID: 23652, channel/marker: metadata/core_marker_id, state: 1, fmt: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u" 0x332be6}
{PID: 23652, channel/marker: ust/potential_exec, state: 0, fmt: " " 0x33d9b6}
{PID: 23652, channel/marker: main/23, state: 0, fmt: "firstarg %d secondarg %s" 0x8048763}
{PID: 23652, channel/marker: main/24, state: 0, fmt: " " 0x80487aa}
{PID: 23652, channel/marker: ust/dummymark, state: 0, fmt: " " 0x8048893}

ustctl --enable-marker main/23 23652

# ustctl --create-trace 23652
# ustctl --start-trace 23652
ustd[23630/23663]: Error: failed to connect to buffer (in consumer_thread() at ustd.c:581)
libustcomm[23630/23666]: Error: connect (path=/tmp/ust-app-socks/23652): Connection refused (in ustcomm_connect_path() at ustcomm.c:581)
ustd[23630/23666]: Warning: unable to connect to process, it probably died before we were able to connect (in connect_buffer() at ustd.c:250)
ustd[23630/23666]: Error: failed to connect to buffer (in consumer_thread() at ustd.c:581)
ustd[23630/23664]: Error: failed to connect to buffer (in consumer_thread() at ustd.c:581)
libustcomm[23630/23665]: Error: connect (path=/tmp/ust-app-socks/23652): Connection refused (in ustcomm_connect_path() at ustcomm.c:581)
ustd[23630/23665]: Warning: unable to connect to process, it probably died before we were able to connect (in connect_buffer() at ustd.c:250)
ustd[23630/23665]: Error: failed to connect to buffer (in consumer_thread() at ustd.c:581)
[7]+  Segmentation fault      ./ustTest

# ustctl --stop-trace 23652
libustcomm[23668/23668]: Error: connect (path=/tmp/ust-app-socks/23652): Connection refused (in ustcomm_connect_path() at ustcomm.c:581)
ustctl[23668/23668]: Error: could not connect to PID 23652 (in ustcmd_send_cmd() at ../libustcmd/ustcmd.c:439)
ustctl[23668/23668]: Error: error while trying to stop trace for PID 23652
 (in main() at ustctl.c:230)

Machine info (non-RT kernel): Intel Core2 Duo
# uname -a
Linux machineName 2.6.18-194.3.1.el5PAE #1 SMP Sun May 2 04:42:25 EDT 2010 i686 i686 i386 GNU/Linux

So ... could the above be related to my glibc patch (or not having a later version of glibc) or are things more broken as they appear?  Maybe I'm missing additional steps that are not documented?

Also a suggestion: for large programs, of many developers and lots of code, it might be somewhat of a hassle to have to enable each and every marker. I would suggest adding a "--enable-all-markers" capability to ustctl.

Thanks

JP




--
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.





  reply	other threads:[~2010-05-20 21:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19  8:49 [ltt-dev] LLTng probes Jyotiswarup Raiturkar
2010-05-19  8:49 ` Jyotiswarup Raiturkar
2010-05-19  8:49 ` Jyotiswarup Raiturkar
2010-05-19 14:30 ` Mathieu Desnoyers
2010-05-20 11:10   ` Jyotiswarup Raiturkar
2010-05-20 14:03     ` Mathieu Desnoyers
2010-05-20 21:50       ` jpaul [this message]
2010-05-20 23:08         ` [ltt-dev] LTT UserSpace Tracer, broken? Mathieu Desnoyers
2010-05-21 18:49         ` Pierre-Marc Fournier
2010-05-24 17:11           ` jpaul
2010-05-28 16:51             ` Pierre-Marc Fournier
     [not found]               ` <A47866F933DF804684068A24BF04A9730862A874@gdrs-exchange.gdrs.com>
     [not found]                 ` <A47866F933DF804684068A24BF04A9730862A878@gdrs-exchange.gdrs.com>
2010-06-19 16:01                   ` Mathieu Desnoyers
2010-05-21  6:43       ` [ltt-dev] LLTng probes Jyotiswarup Raiturkar
2010-05-21 12:23         ` Mathieu Desnoyers

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=A47866F933DF804684068A24BF04A9730862A838@gdrs-exchange.gdrs.com \
    --to=jpaul@gdrs.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox