# uxListRemove() referencing NULL pointer during QueueSend()

**URL:** <https://forums.freertos.org/t/uxlistremove-referencing-null-pointer-during-queuesend/12218>\
**Category:** Kernel\
**Created:** [April 7, 2021, 3:04pm UTC](https://forums.freertos.org/t/uxlistremove-referencing-null-pointer-during-queuesend/12218 "2021-04-07T15:04:00Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [April 7, 2021, 8:48pm UTC](https://forums.freertos.org/t/uxlistremove-referencing-null-pointer-during-queuesend/12218/8 "2021-04-07T20:48:35Z")

</div>

> [@sjenyart](#):
>
> RAc, could you elaborate on the issue you had?

Hi sjenyart,

you’ll find the analysis [here](https://forums.freertos.org/t/problem-with-array-bounds-for-pxreadytaskslists-freertos-8-2-x/12009). In a nutshell, FreeRTOS lists are organized such that the last list element does not have a payload, so trying to use it as a list element WITH a payload will result in looking at invalid memory. Thus, the condition “list length \> 0” along with “the first list element is a terminator” is illegal.

Now how could it happen that a linked list has a length \> 0 but consists of only the terminating element (that is, is empty)? Normally via missing atomicity. Operations that manipulate FreeRTOS lists must not be interruptible by other pieces of code that also manipulate the list; otherwise one thread of execution may change the list count but not be able to adjust the list itself accordingly.

That is a fairly reliable hint that there was no critical section in effect where there should have been one, because the critical section is the one FeeRTOS mechanism that ensures atomicity on the OS level.

In my case, a context switch - which manipulates the task ready list array - was not atomic due to incorrect ordering of the service and sys tick ISRs - service MUST POSITIVELY have the lowest priority since it must only interrupt a task context, never an interrupt context. Thus the sys tick interrupt was being interrupted by the service ISR which broke atomicity on the task ready list.

The next thing to look for, then, is an incorrect usage of the critical section, for example in the guise that an interrupt w/ priority \> MAX\_SYSCALL illegaly performs operations on FreeRTOS lists.

Sorry for the rather elaborate explanation, I hope it gives you a useful pointer or two…

---

_[View the full topic](https://forums.freertos.org/t/uxlistremove-referencing-null-pointer-during-queuesend/12218)._