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
>   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- patched
> with adeos-ipipe-
> Regards
> Steven
> _______________________________________________
> Xenomai-help mailing list
> xenomai-h...@gna.org
> https://mail.gna.org/listinfo/xenomai-help

Xenomai-core mailing list

Reply via email to