Re: [Xenomai] Re : Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/08/2013 04:30 PM, Paolo Minazzi wrote:

> I have a xenomai application with 70 real-time threads.
> Suppose that thread 1 deletes thread 70 with rt_task_delete().
> This is my case.
> 
> I put a breakpoint and run my xenomai application.
> When my breakpoint is reached gdb stops all my xenomai threads.
> 
> If I press "c" to continue, gdb restarts my application,
> that is every thread, one by one (thread 1, thread 2, thread 3,
> .... , thread 70).
> 
> If I press "c" on gdb, the following scenario could happens :
> 
> 1) gdb start thread 1
> 2) thread 1 starts immediately
> 3)   thread 1 delete thread 70 by rt_task_delete()
> ...
> 4) gdb start thread 2
> 5) gdb start thread 3
> 6) gdb start thread 4
> 7) gdb start thread 5
> 8) gdb start thread 6
> ...
> .) gdb start thread 68
> .) gdb start thread 69
> .) gdb start thread 70
> 
> The thread 1 finds thread 70 in debug mode !
> 
> My patch adjust this problem.
> 
> I realize that it is a very special case, but it is my case.
> 
> I'd like to know if the patch is valid or can be written in a different way.
> For example, I could insert my patch directly in xnpod_delete_thread().
> 
> The function unlock_timers() cannot be called from 
> xenomai-2.5.6/ksrc/skins/native/task.c
> because it is defined static. This is a detail. There are simple ways to 
> solve this.


Hi Paolo,

this explanation makes the condition under which you observe the bug
more clear, but this case is supposed to be already handled by Xenomai code.

If you look at do_taskexit_event() in ksrc/nucleus/shadow.c you will see
at the very beginning a test which does exactly the same thing as your
patch.

Normally, any deletion of a xenomai thread should cause this function to
be called. So, some more debugging is necessary to understand what
happens when rt_task_delete is called in your case. Please try to
trigger an I-pipe tracer freeze in xnpod_delete_thread, and have a large
number of points in /proc/ipipe/trace/post_trace_points.

Regard.

-- 
                                                                Gilles.