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

[Paolo Minazzi <Paolo.Minazzi@mitrol.it>]

Il 03/05/2013 3.06, Gilles Chanteperdrix ha scritto:
> The problem, if I understand it correctly, is that timers are locked 
> when you debug your application with gdb (which is correct), but do 
> not restart when they should. What you have done here is essentially 
> restart them upon any SIGSTOP or SIGINT, which means that the timers 
> are in fact not stopped.

Hi Gilles, you understand correctly.

This is an other test that show that timer are locked.
I have also printed the following number :

xnarch_atomic_get(&nkpod->timerlck)

xnarch_atomic_get(&nkpod->timerlck) == 0    means     unlocked
xnarch_atomic_get(&nkpod->timerlck) > 0     means     locked

If I'm stopped with gdb I see 70 (ok, timers locked).
When I restart and all is OK I see 0 (zero, that is timer unlocked).
When I restart ad I have the bug I see 1(bug, I should see zero).

Sometimes, for some reason, timer remains locked.
This is the problem.

>
> What exactly do you do with gdb when the bug happens? Do you restart the
> application with "continue", do you detach de debugger with "detach" or
> something else?
To see the bug I have to

-1- start gdbserver
-2- start gdbclient
-3- handle SIG32 nostop noprint
-4- set brk point #1
-5- set brk point #2
-6- set brk point #3
-7- c to continue (start the program)
-8- it stops on brk point #3
-9- c to continue
-10- it stops on brk point #1
-11- c to continue
-12- it stops on brk point #2
-13- disable brk point #2
-14- c to continue
====> now timers are locked !


Maybe it is interesting that if I remove command -3-

-3- handle SIG32 nostop noprint

at point -12- I begin to receive SIG32 signals.
The SIG32 messages seems be due to detection of a new threads. In this 
moment infact some thread are create.
Maybe these SIG32 signals make confusion.

> What you should do to understand what happens, is to enable the I-pipe
> tracer and trigger a trace freeze when you hit a point where you are
> sure the timers should have been restarted but have not. With enough
> backlog, you may have some luck finding back what happened.
>
> Regards.
>
I have tried but for me for now it is difficult to make a log at the bug 
point.

Thanks
Paolo