Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk <xenoka09@domain.hid>]

Hi,

> The following patch seems to fix the issue, but I am not yet sure
> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c

Yes it does fix it for me too. The output of my "try" program when run with
gdbserver still differs from the output when run standalone, but at least there
are no EPERM results anymore. The first two tasks cycle pthread_cond_wait more
than once.

0 3x 0x0010
1 2x 0x0010
2 1x 0x0010

If I remove the pthread_yield() again there'll be a lockup again, for which I
cannot see an actual reason. Now, there's no need to explain why this code
can enter an endless loop and that it's no good style to do nothing with error
return codes. But.. shouldn't I be able to break in with gdb via gdbserver
anyway and see where the application is stuck? To interrupt - by chance - the
loop in the right moment to be able a look at my result variable "r"...  Even
if the loop is in a RT task with highest priority?

According to
http://www.xenomai.org/index.php/FAQs#How_can_GDB_be_used.3F
there are no limitations. Maybe it is specific to uClinux/linuxthreads/...?

I was originally expecting that I could hit Ctrl-C on the gdb host at any
moment, type "info threads" and get an idea of what is happening in my stuck
app (taking into account that afterwards some threads might have left their
domain just because I interacted).

Kolja