Re: Weird semaphore/timeout behaviour with gdbserver

["François Legal" <devel@thom.fr.eu.org>]

Le Jeudi, Janvier 21, 2021 22:42 CET, Jan Kiszka <jan.kiszka@siemens.com> a écrit:

> On 19.01.21 18:41, François Legal via Xenomai wrote:
> > Le Vendredi, Janvier 08, 2021 19:35 CET, François Legal via Xenomai <xenomai@xenomai.org> a écrit:
> >
> >> Hello,
> >>
> >> Working on ARMv7 with linux 4.4 and xenomai 3.1, I get a strange behaviour when using GDB.
> >> There seem to be troubles with threads pending on semaphores, which do not wake up when sem is posted nor when the timedwait is over.
> >> It does not seem to make a problem with all the semaphores on the software, but at program startup, the behaviour is pretty constant.
> >>
> >> If I start the same program from shell, thread activation works flawlessly.
> >>
> >> ANybody can give a hint on this ?
> >>
> >> Thanks.
> >>
> >> François
> >>
> >>
> >
> > I've got another case with pulse semaphores with timeout, that outline the same behaviour without gdbserver.
> > I've got 2 threads and 2 pulse semaphores. Thread1 (priority 60) successively pends (with 30s timeout) on SEM1 then posts SEM2, while thread2 (priority 52) posts SEM1 then pends (forever) on SEM2. Both semaphores are initialized at 0.
> > I can see from debug log that Thread1 pends on SEM1, then thread2 posts SEM1 and pends SEM2, then thread1 posts SEM2, then thread2 posts SEM1 then pends SEM2, then thread1 pends SEM1, then nothing happens anymore. I thought thread1 should be unblocked (either by thread2 posting SEM1, or by the 30s timeout) but that never happens.
> >
> > What am I getting wrong here ?
> >
>
> These scenarios are hairy without test cases. Can you derive something
> simple, portable from your problems? There is testsuite/smokey/gdb/gdb.c
> for full automated tests, but already something we can compile and run
> locally here, gdb manually operated, would be fine. It would also allow
> to cross-check on x86 and arm64 to see if this is arch-specific.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux


Sorry to reply so late on this, but I've been busy on some other stuff.
I tried to write a simple piece of code that reproduces the problem, but with no luck. In the simple case, the sems work as intended (and thus do not need to honor the timeout).
I'm not sure how I can find the answer on this. Also is there any way to check the state of shored objects like semaphores, mutexes, ...
I read the registry should provide this, but I not able to get more entries than what already present in /proc/xenomai/ (heaps, threads and version)

François