Project

General

Profile

Actions

Bug #403

closed

Continuation of Bug-386: after an instr app hang, the very first enable-channel always failed regardless of how long we wait.

Added by Tan le tran almost 12 years ago. Updated almost 12 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
11/22/2012
Due date:
% Done:

100%

Estimated time:

Description

Description:
============
  Bug-386 has been opened to report that consumerD hang when the instrumented app (that
  is currently being traced on) hang (simulated via a kill -STOP).
  The fix has then been implemented.

  However, now with the fix, after the instrumented application hang (via kill -STOP),
  the very first "enable-channel" always failed. Subsequent "enable-channel" are 
  successful.

Scenario:
=========
    lttng create s1
    sleep 1
    lttng enable-event com_ericsson_cba_trace_testapp_lowtraf:OnePerSecB -u
    sleep 1
    lttng start
    sleep 1
    pkill -STOP TestApp
    sleep 60
    date; lttng create s2
    for a in $(seq 1 2); do (echo " "; echo "lttng enable-channel channel0 -s s2 -u"; \
               date +%T.%N; time lttng enable-channel channel0 -s s2 -u; date +%T.%N; sleep 1); done

From the above, the very first enable-channel always failed.


Files

StopTestApp_HaveToEnableChanTwice_noVVV.log (21.6 KB) StopTestApp_HaveToEnableChanTwice_noVVV.log Terminal log (with out sessiond -vvv) Tan le tran, 11/22/2012 05:53 PM
StopTestApp_HaveToEnableChanTwice_withVVV.log (74.6 KB) StopTestApp_HaveToEnableChanTwice_withVVV.log Terminal log (with sessiond -vvv) Tan le tran, 11/22/2012 05:53 PM
fix-bug403.diff (4.2 KB) fix-bug403.diff David Goulet, 11/27/2012 12:42 PM
Actions

Also available in: Atom PDF