Project

General

Profile

Actions
Copy link

Bug #598

closed

Calling stop_tracing() from the Python bindings does not ensure the trace is readable on return

Added by Jérémie Galarneau almost 11 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Jérémie Galarneau
Target version:
-
Start date:
07/18/2013
Due date:
% Done:

0%

Estimated time:

Description

Some Python tests have been failing randomly for some time on the CI. It seems that the reason for the failure is that Babeltrace tries to open a trace which turns out to be empty.

These tests basically all operate the same way:

  1. create a session
  2. enable all events
  3. start the tracing
  4. launch a test application
  5. stop the session
  6. destroy the session
  7. launch Babeltrace to read the trace

Stopping the trace is currently done by launching a sub-process that invokes "lttng stop". However, it does not wait for the process to finish before trying to read the trace.

The patch attached to this bug report forgoes this mechanism completely and calls lttng_stop_tracing() via the Python bindings. However, the error still occurs which leads me to believe the lttng_stop_tracing() call does not really ensure the trace data is flushed to disk.

Note that this patch also modifies the lttng-tools/tests/regressions/ust/fork/test_fork test to print Babeltrace's stderr output as diagnostic.

$ ./test_fork 
1..6
ok 1 - Fork test application exited normally
Waiting for data availability
not ok 2 - Resulting trace is readable
#[error] Encountered an empty file, but expecting a trace packet header.
#[error] Stream index creation error.
#[error] Open file stream error.
#[warning] [Context] Cannot open_trace of format ctf at path /tmp/tmp68ecst/b99f4e80-efe5-11e2-b4ca-00248c0e622f/ust/pid/fork2-19302-20130718-160751.
#[warning] [Context] cannot open trace "/tmp/tmp68ecst/b99f4e80-efe5-11e2-b4ca-00248c0e622f/ust/pid/fork2-19302-20130718-160751" from /tmp/tmp68ecst/b99f4e80-efe5-11e2-b4ca-00248c0e622f for reading.
#[warning] errors occurred when opening trace "/tmp/tmp68ecst/b99f4e80-efe5-11e2-b4ca-00248c0e622f" for reading, continuing anyway.
#
Bail out!
# Unreadable trace; can't proceed with analysis.

Files

0001-Use-the-lttng_stop_tracing-call-instead-of-the-lttng.patch (2.25 KB) 0001-Use-the-lttng_stop_tracing-call-instead-of-the-lttng.patch Jérémie Galarneau, 07/18/2013 04:28 PM

Related issues 1 (0 open — 1 closed)

Related to LTTng-tools - Bug #741: Possible regression: tracing forking processesInvalid02/26/2014

Actions
Actions
Copy link
 #1

Updated by Jérémie Galarneau over 10 years ago

  • Subject changed from Calling lttng_stop_tracing() does not ensure the trace is readable on return to Calling stop_tracing() from the Python bindings does not ensure the trace is readable on return
  • Priority changed from Normal to Low

This problem can't be reproduced from a test completely written in C which points to the Python bindings being the problem.

Actions
Copy link
 #2

Updated by David Goulet over 10 years ago

  • Status changed from New to Confirmed
  • Assignee set to Jérémie Galarneau
  • Target version deleted (2.4)
Actions
Copy link
 #3

Updated by Jérémie Galarneau almost 10 years ago

We can simplify the implementation of the stop Python bindings since lttng-ctl's printing to stdout behavior has been fixed.

commit 8eb7a5e2b9006c5f675c3809055e8abcdffcdb6f
Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Date:   Wed May 7 14:27:45 2014 -0400

    Fix: Don't output to stdout from lttng-ctl

    Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
    Signed-off-by: David Goulet <dgoulet@efficios.com>
Actions
Copy link
 #4

Updated by Jérémie Galarneau over 9 years ago

  • Status changed from Confirmed to Resolved
Actions
Copy link

Also available in: Atom PDF