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. > > Kolja > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
