Getting stuck in vListInsert loop.

Kernel
1

Dear support,
our code is getting stuck in vListInsert loop.
The list is timers queue. It contains two items, uxNumberOfItems is 5 and the second item points to itself instead of the last item.
I know there are possible reasons described in the loop comment.
But I hope based on previous description, You could explain the reason/ reduce possible reasons.
Because it is very hard to achieve the issue.

Thank You.
Best Regards
Ondrej Pokorny

2

Which hardware platform are you using? Which kernel version are you using? Have you defined configASSERT and enabled stack overflow checking?

3

Hello aggarg and thank You for answer.
Platform:
(Silicon Labs) EFM32GG11B320 (Cortex M4).
Version (from task.h):
#define tskKERNEL_VERSION_NUMBER “V10.2.0”
#define tskKERNEL_VERSION_MAJOR 10
#define tskKERNEL_VERSION_MINOR 2
#define tskKERNEL_VERSION_BUILD 0
configASSERT is defined.
Stack overflow checking #define configCHECK_FOR_STACK_OVERFLOW ( 2 ).

Best Regards
Ondrej

4

Seems like an issue that would happen because of incorrectly configured interrupt priorities - but if you have define configASSERT, it should be caught. Can you try to narrow down the problematic part by stopping your application interrupts? You can also try to update to the latest version.

5

Hello aggarg,
I am afraid I cannot stop interrupts.
I have asked the question to narrow down the issue from “the lower level”, i.e. if described list status implies that the same item was added multiple times and how could this happen.

Thank You.
Best Regards
Ondrej

6

If list coherency is not guaranteed, corrupted linked list is one possible manifestation of the problem.

Are you sure to follow the isr-os interaction rules, ie only use …FromISR APIs in isrs and only from isrs running not above MAX_SYSCALL isr priority?

7

This page describes configMAX_SYSCALL_INTERRUPT_PRIORITY and related concepts in detail - RTOS for ARM Cortex-M.

8

Hello and thank You for remarks.
Timer task has the highest priority (configTIMER_TASK_PRIORITY = 5).
We seem not to call Timer APIs from ISRs.

But when checking our code I have found a few violations of rule:
“timer callback function must not call vTaskDelay(), vTaskDelayUntil(), or specify a non zero block time when accessing a queue or a semaphore” (FreeRTOS timers documentation)
or
" Do not use a block time if calling a timer API function from a timer callback function, as doing so could cause a deadlock! " (Code comment in library)

Could it be the explanation of the issue?
Could You please describe how the deadlock is made?

Thank You.
Best Regards
Ondrej

9

The issue is that while a timer callback is running, and blocked, the Timer Task can not process other requests or call other timer callbacks.

So, it isn’t that this will somehow corrupt structures, but might let the Timer Command queue fill or other timers callbacks get delayed unacceptably.

The list corruption could be a wild write somewhere, or manipulating a timer when it shouldn’t be, like after being deleted.