[Xenomai-help] Periodic threads not scheduled anymore during debug session

[Xenomai-help] Periodic threads not scheduled anymore during debug session

[Steven Kauffmann]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hi all,

If I connect a debugger to my application, other Xenomai periodic
threads (threads that not belong to the current process I'm debugging
) are not scheduled anymore. Attached you can find a simple example
that reproduces the problem. I run the program 2 times in a different
terminal and connected a debugger to one of them. When a breakpoint is
reached both programs stops their execution but I would expect that
only the program that I'm debugging should stop and not both.

$ cat /proc/xenomai/sched

CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
  0  0       -1      0          0          master    R          ROOT
  0  5469     0      1000000001 331274938  master    D
  0  5471     0      1000000001 0          master    XT

This looks normal one thread is stopped ( thread that reaches the
breakpoint ) and the other one is delayed because it's a periodic
thread. Every time I call this command the timeout of the delayed
thread changes so it looks like this thread is still running but in
reality it is not.

I'm using the xenomai 2.4 branch and kernel linux-2.6.28.9 patched
with adeos-ipipe-2.6.28.9-x86-2.2-07.

Regards

Steven

[-- Attachment #2: test_gdb.c --]
[-- Type: text/x-csrc, Size: 1105 bytes --]

#include <sys/mman.h>
#include <native/task.h>
#include <native/timer.h>

RT_TASK task;

void mytask(void* cookie) {

  int ret;

  ret = rt_task_set_periodic(&task, TM_NOW, 1000000000);
  if(ret != 0) {
    printf("Error: rt_task_set_period returned %d\n", ret);
    rt_task_delete(&task);
    return;
  }

  int counter = 0;

  while(1) {
    printf("Counter: %d\n", counter);
    counter++;
    rt_task_wait_period(NULL);
  }

}

int main() {

  int ret;

  mlockall(MCL_CURRENT|MCL_FUTURE);

  ret = rt_task_create(&task, NULL, 0, 0, 0);
  if(ret != 0) {
    printf("Error: rt_task_create returned %d\n", ret);
    return -1;
  }

  ret = rt_task_start(&task, &mytask, NULL);
  if(ret != 0) {
    printf("Error: rt_task_start returned %d\n", ret);
    return -1;
  }

  ret = rt_task_set_periodic(&task, TM_NOW, 1000000000);
  if(ret != 0) {
    printf("Error: rt_task_set_period returned %d\n", ret);
    rt_task_delete(&task);
    return -1;
  }

  getchar();

  ret = rt_task_delete(&task);
  if(ret != 0) {
    printf("Error: rt_task_delete returned %d\n", ret);
    return -1;
  }

  return 0;
}

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Philippe Gerum]

On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
> Hi all,
> 
> If I connect a debugger to my application, other Xenomai periodic
> threads (threads that not belong to the current process I'm debugging
> ) are not scheduled anymore. Attached you can find a simple example
> that reproduces the problem. I run the program 2 times in a different
> terminal and connected a debugger to one of them. When a breakpoint is
> reached both programs stops their execution but I would expect that
> only the program that I'm debugging should stop and not both.
> 
> $ cat /proc/xenomai/sched
> 
> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>   0  0       -1      0          0          master    R          ROOT
>   0  5469     0      1000000001 331274938  master    D
>   0  5471     0      1000000001 0          master    XT
> 
> This looks normal one thread is stopped ( thread that reaches the
> breakpoint ) and the other one is delayed because it's a periodic
> thread. Every time I call this command the timeout of the delayed
> thread changes so it looks like this thread is still running but in
> reality it is not.

This behavior is wanted (I mean, the implementation does freeze all
thread timers when a break state is reached on purpose), so that you
don't get tons of overruns once the debuggee is restarted.

However, I'm now wondering if we should not be a bit smarter than this,
and narrow the scope of such action. We do have the mechanisms to do so,
it is just a matter of using them.

> 
> I'm using the xenomai 2.4 branch and kernel linux-2.6.28.9 patched
> with adeos-ipipe-2.6.28.9-x86-2.2-07.
> 
> Regards
> 
> Steven
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
>> Hi all,
>>
>> If I connect a debugger to my application, other Xenomai periodic
>> threads (threads that not belong to the current process I'm debugging
>> ) are not scheduled anymore. Attached you can find a simple example
>> that reproduces the problem. I run the program 2 times in a different
>> terminal and connected a debugger to one of them. When a breakpoint is
>> reached both programs stops their execution but I would expect that
>> only the program that I'm debugging should stop and not both.
>>
>> $ cat /proc/xenomai/sched
>>
>> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>>   0  0       -1      0          0          master    R          ROOT
>>   0  5469     0      1000000001 331274938  master    D
>>   0  5471     0      1000000001 0          master    XT
>>
>> This looks normal one thread is stopped ( thread that reaches the
>> breakpoint ) and the other one is delayed because it's a periodic
>> thread. Every time I call this command the timeout of the delayed
>> thread changes so it looks like this thread is still running but in
>> reality it is not.
> 
> This behavior is wanted (I mean, the implementation does freeze all
> thread timers when a break state is reached on purpose), so that you
> don't get tons of overruns once the debuggee is restarted.
> 
> However, I'm now wondering if we should not be a bit smarter than this,
> and narrow the scope of such action. We do have the mechanisms to do so,
> it is just a matter of using them.

Do we? I mean, are we able to know which process a timer belongs to?

-- 
                                                 Gilles.

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Philippe Gerum]

On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
> >> Hi all,
> >>
> >> If I connect a debugger to my application, other Xenomai periodic
> >> threads (threads that not belong to the current process I'm debugging
> >> ) are not scheduled anymore. Attached you can find a simple example
> >> that reproduces the problem. I run the program 2 times in a different
> >> terminal and connected a debugger to one of them. When a breakpoint is
> >> reached both programs stops their execution but I would expect that
> >> only the program that I'm debugging should stop and not both.
> >>
> >> $ cat /proc/xenomai/sched
> >>
> >> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
> >>   0  0       -1      0          0          master    R          ROOT
> >>   0  5469     0      1000000001 331274938  master    D
> >>   0  5471     0      1000000001 0          master    XT
> >>
> >> This looks normal one thread is stopped ( thread that reaches the
> >> breakpoint ) and the other one is delayed because it's a periodic
> >> thread. Every time I call this command the timeout of the delayed
> >> thread changes so it looks like this thread is still running but in
> >> reality it is not.
> > 
> > This behavior is wanted (I mean, the implementation does freeze all
> > thread timers when a break state is reached on purpose), so that you
> > don't get tons of overruns once the debuggee is restarted.
> > 
> > However, I'm now wondering if we should not be a bit smarter than this,
> > and narrow the scope of such action. We do have the mechanisms to do so,
> > it is just a matter of using them.
> 
> Do we? I mean, are we able to know which process a timer belongs to?
> 

We could tag the per-thread timers (rtimer, ptimer) using their status
field, and move back to the owner thread using container_of() when
applicable.

-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
>>>> Hi all,
>>>>
>>>> If I connect a debugger to my application, other Xenomai periodic
>>>> threads (threads that not belong to the current process I'm debugging
>>>> ) are not scheduled anymore. Attached you can find a simple example
>>>> that reproduces the problem. I run the program 2 times in a different
>>>> terminal and connected a debugger to one of them. When a breakpoint is
>>>> reached both programs stops their execution but I would expect that
>>>> only the program that I'm debugging should stop and not both.
>>>>
>>>> $ cat /proc/xenomai/sched
>>>>
>>>> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>>>>   0  0       -1      0          0          master    R          ROOT
>>>>   0  5469     0      1000000001 331274938  master    D
>>>>   0  5471     0      1000000001 0          master    XT
>>>>
>>>> This looks normal one thread is stopped ( thread that reaches the
>>>> breakpoint ) and the other one is delayed because it's a periodic
>>>> thread. Every time I call this command the timeout of the delayed
>>>> thread changes so it looks like this thread is still running but in
>>>> reality it is not.
>>> This behavior is wanted (I mean, the implementation does freeze all
>>> thread timers when a break state is reached on purpose), so that you
>>> don't get tons of overruns once the debuggee is restarted.
>>>
>>> However, I'm now wondering if we should not be a bit smarter than this,
>>> and narrow the scope of such action. We do have the mechanisms to do so,
>>> it is just a matter of using them.
>> Do we? I mean, are we able to know which process a timer belongs to?
>>
> 
> We could tag the per-thread timers (rtimer, ptimer) using their status
> field, and move back to the owner thread using container_of() when
> applicable.

What if an application uses rt_alarm_create/rt_alarm_wait?

-- 
                                                 Gilles.

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Philippe Gerum]

On Wed, 2009-05-13 at 15:34 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >>> On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
> >>>> Hi all,
> >>>>
> >>>> If I connect a debugger to my application, other Xenomai periodic
> >>>> threads (threads that not belong to the current process I'm debugging
> >>>> ) are not scheduled anymore. Attached you can find a simple example
> >>>> that reproduces the problem. I run the program 2 times in a different
> >>>> terminal and connected a debugger to one of them. When a breakpoint is
> >>>> reached both programs stops their execution but I would expect that
> >>>> only the program that I'm debugging should stop and not both.
> >>>>
> >>>> $ cat /proc/xenomai/sched
> >>>>
> >>>> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
> >>>>   0  0       -1      0          0          master    R          ROOT
> >>>>   0  5469     0      1000000001 331274938  master    D
> >>>>   0  5471     0      1000000001 0          master    XT
> >>>>
> >>>> This looks normal one thread is stopped ( thread that reaches the
> >>>> breakpoint ) and the other one is delayed because it's a periodic
> >>>> thread. Every time I call this command the timeout of the delayed
> >>>> thread changes so it looks like this thread is still running but in
> >>>> reality it is not.
> >>> This behavior is wanted (I mean, the implementation does freeze all
> >>> thread timers when a break state is reached on purpose), so that you
> >>> don't get tons of overruns once the debuggee is restarted.
> >>>
> >>> However, I'm now wondering if we should not be a bit smarter than this,
> >>> and narrow the scope of such action. We do have the mechanisms to do so,
> >>> it is just a matter of using them.
> >> Do we? I mean, are we able to know which process a timer belongs to?
> >>
> > 
> > We could tag the per-thread timers (rtimer, ptimer) using their status
> > field, and move back to the owner thread using container_of() when
> > applicable.
> 
> What if an application uses rt_alarm_create/rt_alarm_wait?

Those do not create per-thread timers. We just want to follow a bit more
the principle of least surprise, and prevent common programming patterns
to be affected by this feature.

For the rest, we would have to reverse the current logic and tag
blockable timers instead of non-blockable one. The shadow code would
then have to tag the ptimer/rtimer of the ptraced thread as blockable,
leaving all other timers as unblockable by default.

> 
-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[thomas.debes]

> -----Ursprüngliche Nachricht-----
> Von: xenomai-core-bounces@domain.hid [mailto:xenomai-core-bounces@domain.hid]
> Im Auftrag von Philippe Gerum
> Gesendet: Mittwoch, 13. Mai 2009 15:42
> An: Gilles Chanteperdrix
> Cc: Steven Kauffmann; xenomai@xenomai.org
> Betreff: Re: [Xenomai-core] [Xenomai-help] Periodic threads not
> scheduled anymore during debug session
> 
> On Wed, 2009-05-13 at 15:34 +0200, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote:
> > >> Philippe Gerum wrote:
> > >>> On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> If I connect a debugger to my application, other Xenomai
> periodic
> > >>>> threads (threads that not belong to the current process I'm
> debugging
> > >>>> ) are not scheduled anymore. Attached you can find a simple
> example
> > >>>> that reproduces the problem. I run the program 2 times in a
> different
> > >>>> terminal and connected a debugger to one of them. When a
> breakpoint is
> > >>>> reached both programs stops their execution but I would expect
> that
> > >>>> only the program that I'm debugging should stop and not both.
> > >>>>
> > >>>> $ cat /proc/xenomai/sched
> > >>>>
> > >>>> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT
> NAME
> > >>>>   0  0       -1      0          0          master    R
> ROOT
> > >>>>   0  5469     0      1000000001 331274938  master    D
> > >>>>   0  5471     0      1000000001 0          master    XT
> > >>>>
> > >>>> This looks normal one thread is stopped ( thread that reaches
> the
> > >>>> breakpoint ) and the other one is delayed because it's a
> periodic
> > >>>> thread. Every time I call this command the timeout of the
> delayed
> > >>>> thread changes so it looks like this thread is still running but
> in
> > >>>> reality it is not.
> > >>> This behavior is wanted (I mean, the implementation does freeze
> all
> > >>> thread timers when a break state is reached on purpose), so that
> you
> > >>> don't get tons of overruns once the debuggee is restarted.
> > >>>
> > >>> However, I'm now wondering if we should not be a bit smarter than
> this,
> > >>> and narrow the scope of such action. We do have the mechanisms to
> do so,
> > >>> it is just a matter of using them.
> > >> Do we? I mean, are we able to know which process a timer belongs
> to?
> > >>
> > >
> > > We could tag the per-thread timers (rtimer, ptimer) using their
> status
> > > field, and move back to the owner thread using container_of() when
> > > applicable.
> >
> > What if an application uses rt_alarm_create/rt_alarm_wait?
> 
> Those do not create per-thread timers. We just want to follow a bit
> more
> the principle of least surprise, and prevent common programming
> patterns
> to be affected by this feature.
> 
> For the rest, we would have to reverse the current logic and tag
> blockable timers instead of non-blockable one. The shadow code would
> then have to tag the ptimer/rtimer of the ptraced thread as blockable,
> leaving all other timers as unblockable by default.
> 
> >

Do you know when this will be implemented? 

We have a kernel watchdog service running (Xenomai task) which always restarts our system while debugging (because the watchdog is not triggered anymore). I assume that this problem is related to the one above.

Thanks
Thomas

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session

[Philippe Gerum]

On Wed, 2009-05-27 at 11:23 +0200, thomas.debes@domain.hid wrote:
> > 
> > For the rest, we would have to reverse the current logic and tag
> > blockable timers instead of non-blockable one. The shadow code would
> > then have to tag the ptimer/rtimer of the ptraced thread as blockable,
> > leaving all other timers as unblockable by default.
> > 
> > >
> 
> Do you know when this will be implemented? 
> 

No idea, yet. This is certainly something to work on at some point
though.

> We have a kernel watchdog service running (Xenomai task) which always restarts our system while debugging (because the watchdog is not triggered anymore). I assume that this problem is related to the one above.
> 
> Thanks
> Thomas
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
-- 
Philippe.