Weird semaphore/timeout behaviour with gdbserver

Jan Kiszka jan.kiszka at siemens.com
Thu Jan 21 22:42:17 CET 2021


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 at 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



More information about the Xenomai mailing list