Re: [Xenomai-help] gdb/gdbserver hangs during rt_task_create

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

Philippe Gerum wrote:
> On Wed, 2010-12-22 at 20:00 +0100, Kolja Waschk wrote:
>>>> In my actual application however I never get past the rt_task_create, even if
>>>> I set a breakpoint at some line somewhen later.
>>> What if you don't single step but (c)ontinue?
>> It "hangs".
>>
>> But wait, just in this moment I discovered that I can get further if I
>> set all priorities, i.e. priority of the main task (with rt_task_shadow) and the
>> tasks where I couldn't get past rt_task_create, to 0 instead of 49 as before. Then at
>> least "cont" works to the next breakpoint (stepping over with "next" still doesn't).
>>
> 
> This is typically a linuxthreads issue. Because there is a hidden
> manager in the loop which wants to get involved into the process of
> starting other threads, you can end up with priority issues breaking the
> internal protocol. The manager thread is not known from Xenomai, so in
> your case, it looks like starved from CPU albeit other threads expect it
> to kick in at some point. This can only happen if some of the protocol
> is based on busy waiting, which seems to be the case there.
> 
>> Debugging with gdb at the moment feels unnecessarily complicated. Very often
>> the "next" doesn't bring me to the next line in my current source, but to some unexpected
>> place (e.g. to a rt_mutex_acquire_inner() which was called in a subroutine four
>> levels deeper..). I don't remember me becoming that confused with my previous
>> setup (Blackfin 2.6.28 kernel with Xenomai 2.4.7) or in other C++ apps ;)
> 
> This is likely not related to the runtime environment at all. GDB has
> not a great track record when it comes to multi-thread debugging even if
> the situation improved over time, and things tend to get worse when
> linuxthreads are in the loop because of the number of magic interactions
> with the manager thread, and use of signals internally. What does have
> an impact is your toolchain and how aggressive it is when optimizing the
> code. What you see is not what you get in that case.

And gdb 6.5 over linuxthreads is pretty much outdated... Also, some bugs
have been fixed in Xenomai 2.5.3. So, I think it is useless pursuing
investigating this issue until you can confirm that you can reproduce it
with current versions of libc, gdb and Xenomai.

-- 
                                                                Gilles.