Fix: Add arbitrary wait period for kernel streaming test

Once the trace has been destroy, there is a race condition between
reading the trace and the trace being completely written on disk.

We don't have anyway of telling if the streamed trace has been completed
so we have to add an arbitrary wait period so the test can successfully
parse and validate the trace.

I never hit that problem until this morning with my Linux 3.6.0 kernel.
Maybe related or not, still the trace can occur on slower systems.

Signed-off-by: David Goulet <dgoulet@efficios.com>

diff --git a/tests/tools/streaming/run-kernel b/tests/tools/streaming/run-kernel
index b64f233b8fa612f27ff307b56e8409c36e5cac74..7d6324d296e79609b3d6a5b226ee128c7a2c2d4e 100755 (executable)
--- a/tests/tools/streaming/run-kernel
+++ b/tests/tools/streaming/run-kernel
@@ -80,6 +80,15 @@ function test_kernel_before_start ()
        sleep 1
        stop_lttng_tracing $SESSION_NAME
        destroy_lttng_session $SESSION_NAME
+
+       # We can not predict _yet_ when the trace is available so we have to do a
+       # arbitratry sleep to validate the trace.
+       echo -n "Waiting 3 seconds for the trace to be written on disk "
+       for i in `seq 1 3`; do
+               echo -n "."
+               sleep 1
+       done
+       echo ""
 }
 
 # Deactivated since this feature is not yet available where we can enable