# Crash in vListInsert due to xValueOfInsertion is equal to pxNext-\>xItemValue

**URL:** <https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369>\
**Category:** Kernel\
**Created:** [November 14, 2014, 5:54pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369 "2014-11-14T17:54:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 14, 2014, 5:54pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/1 "2014-11-14T17:54:39Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Friday, November 14, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#efbd):

Hi there,  
i’m just experiencing problems that freertos locks up in vListInsert, exactly at this line:

for( pxIterator = ( xListItem \* ) &( pxList-\>xListEnd ); pxIterator-\>pxNext-\>xItemValue \<= xValueOfInsertion; pxIterator = pxIterator-\>pxNext )

when calling xQueueReceive with portMAX\_DELAY  
Theres only one line in a thread where i’m using the queue,  
and only one thread where I’m sending something to the queue (also only once).

I checked out the note directly above the freeze, nothing of this things caused the problem.  
I checked out the stacks, interupt priorities (i know the speciality of Cortex-M3 with priorities) and so on…  
Then i saw the comment above the NOTE:

/\* If the list already contains a list item with the same item value then  
the new list item should be placed after it. This ensures that TCB’s which  
are stored in ready lists (all of which have the same ulListItem value)  
get an equal share of the CPU. However, if the xItemValue is the same as  
the back marker the iteration loop below will not end. This means we need  
to guard against this by checking the value first and modifying the  
algorithm slightly if necessary. \*/

After checking out the values of xValueOfInsertion and pxNext-\>xItemValue, i discovered that both entries have the same value (its always “3”), and theres only one item in the list (pxList-\>uxNumberOfItems == 1).  
I just coudln’t exactly figure out, when the xItemValue is set, and what the value it has means. Is it used in different cases? Sometimes something with priorities is assigned to it and sometimes a delay-value…  
What can i do to avoid the problem of 2 same xItemValues like described in the comment i found in the code?  
Anyone else having this trouble?

EDIT:  
Just checked out pointer-values in the pxIterator-struct. They seems correct, beacuse pxNext and pxPrevious have the same adress (adress is located im ram-region), this seems to be correct, cause there is only one item there.

Thx for responses.  
Best regards,  
David

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 14, 2014, 6:38pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/2 "2014-11-14T18:38:31Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, November 14, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#7dac):

I’m not sure I follow your post, but suspect the comments you are quoting are not related as they refer to the case where the value of the item being inserted is portMAX\_DELAY. portMAX\_DELAY is either 0xffffffff or 0xffff depending on whether you are using a 32, 16 or 8-bit architecture.

> when calling xQueueReceive with portMAX\_DELAY  
> Theres only one line in a thread where i’m using the queue,  
> and only one thread where I’m sending something to the queue  
> (also only once).

Could you post the code that is both sending and receiving on the queue.

> Then i saw the comment above the NOTE:

I think that comment is in list.c.

> After checking out the values of xValueOfInsertion and  
> pxNext-\>xItemValue, i discovered that both entries have  
> the same value (its always “3”)

As above, I think that comment is only related to the case where the value of the item being inserted is portMAX\_DELAY.

> I just coudln’t exactly figure out, when the xItemValue is set,  
> and what the value it has means

It depends on which list item it is the value for - in this case I suspect it represents the priority of the task so the tasks are blocked in priority order (it is actually configMAX\_PRIORITIES minus the tasks priority).

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 11:08am UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/3 "2014-11-15T11:08:21Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#e0bc):

Hi, thx for the fast response - I’ll try to make my problem a little  
bit more clear.

Here’s the code:

#define configMAX\_PRIORITIES 5  
Task 1 has a Priority of 2  
Task 2 has a Priority of 3

In task 1, a message is sent to task 2, and then waits for the response.

> //Make sure response queue is empty  
> while(xQueueReceive(CAN\_SDO\_ResponseQueue, &retval\_u32, 0) == pdTRUE);
> 
> retval\_u32 = CAN\_SDO\_STATE\_START\_TRANSFER;  
> xQueueSendToBack(CAN\_SDO\_TransferQueue, &retval\_u32, 0); //Send to Task 2
> 
> _**xQueueReceive(CAN\_SDO\_ResponseQueue, &retval\_u32, portMAX\_DELAY) ← Here, the lock happens**_

This is where task 2 waits for work from task 1, after doing the work, it posts back into the CAN\_SDO\_ResponseQueue.

> if(xQueueReceive(CAN\_SDO\_TransferQueue, &MsgAnswer\_u32, 0) == pdTRUE)  
> //Do the work…  
> xQueueSendToBack(CAN\_SDO\_ResponseQueue, &MsgAnswer\_u32, 0); //No delay needed, queue should be empty anyway…

So, just to make my problem a little bit clearer:  
The lock happens exactly in this line in list.c - file:

> for( pxIterator = ( xListItem \* ) &( pxList-\>xListEnd ); **pxIterator-\>pxNext-\>xItemValue** \<= **xValueOfInsertion** ; pxIterator = pxIterator-\>pxNext )  
> {  
> /\* There is nothing to do here, we are just iterating to the  
> wanted insertion position. \*/  
> }

In the list, theres only one item (pointed to by pxNext and pxPrevious)  
**pxIterator-\>pxNext-\>xItemValue** has a value of 3.  
**xValueOfInsertion** has a value of 3.

When I understand the loop correctly, this causes a lock-up because the abort-condition is never met:

> pxIterator-\>pxNext-\>xItemValue \<= xValueOfInsertion

When xItemValue is representing the priority (of what?), then everytime an item with  
same or higher priority should be placed in the list, it would cause a lock-up.

I just couldn’t figure out what this list ist actualy used for?  
And what can i then do to avoid this lock-ups?

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 15, 2014, 11:22am UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/4 "2014-11-15T11:22:29Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#8e3d):

It looks like the list has already been corrupted because the last item in the list should always have an item value of 0xffffffff (assuming 32-bit). Therefore the loop will always terminate at some point (assuming no corruption) on the \<= test because there should be something with an item value of 0xffffffff, and that code can only execute if the item value being inserted is less than 0xffffffff.

This type of corruption can often happen because of invalid interrupt priorities. Are you using **any** interrupts in your application (other than the RTOS interrupts)? For example, is you CAN peripheral interrupt driven?

What version of FreeRTOS are you using? Do you have configASSERT() defined?

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 12:12pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/5 "2014-11-15T12:12:45Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#8bec):

Yes i use lot’s of interrupts, it’s just, the application itself is in testing for more than 2 years now, and i never experienced such an issue until now.

I’m using FreeRTOS V7.0.2. Actually I don’t have configASSERT defined, but I’ll checkit out now, thx for the hint!

Here’s the list of Interrupt-Priorities and my config:

```
#define configKERNEL_INTERRUPT_PRIORITY 255
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 48 // equivalent to 0x30, or priority 3.

#define USB_IRQ_PRIO 4 //USB
#define TIMER7_IRQ_PRIO 14 //USB Delay
#define DISP_MOSI_DMA_IRQ_PRIO 13 //LCD
#define DISP_TIM_IRQ_PRIO 13 //LCD
#define TIMER2_IRQ_PRIO 10 //RTOS Runtimestats
#define FOB_IRQ_PRIO 5 //FOB
#define FOB_TX_DMA_IRQ_PRIO 5 //FOB
#define FOB_TIMER_IRQ_PRIO 5 //FOB
#define ADC_DMA2_STREAM3_IRQ_PRIO 14 //ADC
#define ADC_OC_IRQ_PRIO 0 //ADC-Overcurrent --> must not be delayed The ISR does not call any FreeRTSO API functions
#define EFLASH_IRQ_PRIO 6
#define EEPROM_IRQ_PRIO 6
#define DSP_DMA_IRQ_PRIO 9 //DSP_COM
#define DSP_USART_IRQ_PRIO 9 //DSP_COM
#define DSP_TIMER_IRQ_PRIO 9 //DSP_COM

```

All interrupts until here worked for more than 2 years now without a problem

The CAN-Interrupts were added recently

```
#define CAN_RX0_IRQ_PRIO 4 //CAN-Com
#define CAN_RX1_IRQ_PRIO 5 //CAN-Com
#define CAN_TX_IRQ_PRIO 5 //CAN-Com
#define CAN_ERR_IRQ_PRIO 4 //CAN-Com

```

Since I’m using an STM32F205, I use the ST-standardlibrary to configure the interrupts, this looks like that:

```
NVIC_InitTypeDef NVIC_InitStructure;
NVIC_InitStructure.NVIC_IRQChannel = CAN1_RX0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = CAN_RX0_IRQ_PRIO;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); // 4 bits for pre-emption priority 0 bits for subpriority.

```

I just did an additional testing with the last thing i changed: i use a mutex to block the transmission of CAN\_Messages in a function CAN\_Transmit(). CAN\_Transmit doesn’t free the mutex. To get a minimum time between 2 CAN-Messages, i start a Softwaretimer with 5ms Delay  
and the Callback-Function then calls xSemaphoreGive();.

```
void CAN_TxDelayTimerCallback(xTimerHandle pxTimer)
{
    //Senden wieder freigeben
    xSemaphoreGive(CAN_TxMutex);
}

```

When i remove the Software-Timer and give back the Mutex directly in the CAN\_Transmit-Message, everything just works fine. Need to investigate this further.

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 12:28pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/6 "2014-11-15T12:28:44Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#ec7d):

Just tried out configASSERT like this:

```
#define configASSERT(x) if(x == 0) vAssertCalled( __FILE__ , __LINE__ )

void vAssertCalled( void *pfile, uint32_t line)
{
	while(1);
}

```

vAssertCalled is never called, although the lock-up occurs.

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 15, 2014, 12:33pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/7 "2014-11-15T12:33:21Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#8bec/eea9):

> I’m using FreeRTOS V7.0.2. Actually I don’t have configASSERT defined,  
> but I’ll checkit out now, thx for the hint!

That is a relatively old version. Later versions include additional  
configASSERT() calls to trap invalid interrupt priorities, but your  
version probably doesn’t.

> Here’s the list of Interrupt-Priorities and my config:

That all looks fine.

> I just did an additional testing with the last thing i changed: i use a  
> mutex to block the transmission of CAN\_Messages in a function  
> CAN\_Transmit(). CAN\_Transmit doesn’t free the mutex. To get a minimum  
> time between 2 CAN-Messages, i start a Softwaretimer with 5ms Delay  
> and the Callback-Function then calls xSemaphoreGive();.
> 
> void CAN\_TxDelayTimerCallback(xTimerHandle pxTimer)  
> {  
> //Senden wieder freigeben  
> xSemaphoreGive(CAN\_TxMutex);  
> }

I would have to dig out V7.0.2 to determine the effect of giving a mutex  
from a task other than the mutex holder. The behaviour has changed  
recently, so the latest version I have on my PC is not helpful in that  
regards.

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 12:55pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/8 "2014-11-15T12:55:31Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#dda2):

I just realized, that it might have something to do with the priority of the  
Software-Timer. Previously the priority was set to 3.  
The lock-up occured almost everytime when i called CAN\_Transmit() without delay in between.  
Like:

```
CAN_Transmit(FrameA);
//Task should be blocked on second call of CAN_Transmit, until Software-Timer-Callback is called and give back the Mutex.
CAN_Transmit(FrameB);

```

The CAN\_Transmit-Function looks like this:

```
uint8_t CAN_TxMessage(frame)
{
    xSemaphoreTake(CAN_TxMutex, portMAX_DELAY);
    
    //sending frame...

    //If time couldn't be startet, free Mutex anyway
    if(xTimerStart(CAN_TxDelayTimer,0) != pdPASS)
    {
        xSemaphoreGive(CAN_TxMutex);
    }
    return pass;
}

```

After changing the priority to 5, the lockup still occurs, but much less regularly,  
just like once every 10 minutes or so. (the Frames are sent every 100ms).

I think i check out the newest version of FreeRTOS, it might be resolved by itself then…

Just wanted to say thx for the help so far!

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\
**Post date:** [November 15, 2014, 1:07pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/9 "2014-11-15T13:07:42Z")

</div>

**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#892c):

Hi David,

Just to make sure that you’re looking at what you think you’re looking at, a small patch:

```auto
-#define configASSERT(x) if(x == 0) vAssertCalled( __FILE__ , __LINE__ )
+#define configASSERT(x) if((x) == 0) vAssertCalled( __FILE__ , __LINE__ )

+volatile int error_caught;
+
 void vAssertCalled( void *pfile, uint32_t line)
 {
+	portDISABLE_INTERRUPTS( );
 	while(1)
+	{
+ // A debugger will stop here on a break
+ error_caught++;
+	}
 }

```

1. Before the while(1), try to disable further interrupts.
2. A macro parameter shall be put between parentheses

ad 1) It has happened to me that one task was caught in vAssertCalled() while other tasks were still running.

ad 2) The parentheses will change the outcome:

```auto
	configASSERT( A && B );
	if( A && B == 0 ) // wrong
	if( ( A && B ) == 0 ) // ok

```

I assume you didn’t make mistakes in the choice of the FromISR() versions:

```auto
	xQueueSend() <> xQueueSendFromISR()
	xQueueReceive() <> xQueueReceiveFromISR()
	xSemaphoreGive() <> xSemaphoreGiveFromISR()
	xEventGroupSetBits() <> xEventGroupSetBitsFromISR()
	...

```

Good luck,  
Hein

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 15, 2014, 1:13pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/10 "2014-11-15T13:13:27Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#1f65):

I just stepped through the following code in V7.0.2 and cannot see a reason why it would not be valid:

```
staticvoidprvCallback( xTimerHandle xTimer )
{
  xSemaphoreGive( xMutex );
}/\*----------------------------------\*/

static void prvCheckTask( void \*pvParameters )  
{  
xTimerHandle xTimer;

/\* Just to remove compiler warning. \*/  
( void ) pvParameters;  
xTimer = xTimerCreate( “timer”,  
50,  
pdFALSE,  
NULL,  
prvCallback );

/\* Start with the mutex held. \*/  
xSemaphoreTake( xMutex, portMAX\_DELAY );

for( ;; )  
{  
/\* Start the timer to give the mutex. \*/  
xTimerStart( xTimer, portMAX\_DELAY );

```
<span style="color: #888888">/* Take the semaphore, which will only be available</span>

```

when the timer gives it. \*/  
xSemaphoreTake( xMutex, portMAX\_DELAY );  
}  
}
```

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 1:27pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/11 "2014-11-15T13:27:55Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#892c/4012):

Hi Hein,  
thx for your patch - although the result keeps the same ☹

I checked out the FromISR() and normal Calls and i think they are all fine.  
What makes me suspicious, is that the lock doesn’t occur every time the functions are called, sometimes it can be called several times befor lock occurs, and with a misplaced xQueue… this wouldn’t be the case?

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 1:35pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/12 "2014-11-15T13:35:34Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#8fcb):

What can be a reason for the list to be corrupted ?  
Except of those things can be found in the note

1. Stack overflow
2. Incorrect interrupt priority assignment, especially on Cortex-M parts where numerically high priority values denote low actual interrupt priorities, which can seem counter intuitive.
3. Calling an API function from within a critical section or when the scheduler is suspended, or calling an API function that does not end in “FromISR” from an interrupt.
4. Using a queue or semaphore before it has been initialised or before the scheduler has been started (are interrupts firing before TaskStartScheduler() has been called?).

It’s just to make it easier for me, that i know what to look for in the code.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 15, 2014, 1:47pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/13 "2014-11-15T13:47:01Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#8fcb/c23d):

The usual suspects are in the code comments you have already quoted. I  
presume you have also read through this:  
[http://www.freertos.org/FAQHelp.html](http://www.freertos.org/FAQHelp.html)

Of course any misbehaving code could just be writing over the data  
structures.

Which heap\_n.c file are you using? If heap\_3.c could it be your stack  
and heap crashing into each other?

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 2:49pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/14 "2014-11-15T14:49:58Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#065a):

Uhm, yeah i guess i just solved the problem.  
I updated to the newest Version of FreeRTOS and the configASSERT just gave me the solution.  
I called xTimerIsTimerActive() from withing an ISR.  
I thought, when implementing this, that it’s ok because there is no FromISR port of this function and there’s no prohibition in API reference.

Just worked around with setting a variable and now it just works fine.

Is there a possibility to check out if the timer is active from within an ISR?

Sorry guys for consuming so much time from you with such a stupid mistake made by me!  
Thank you so much for your help!

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 15, 2014, 3:08pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/15 "2014-11-15T15:08:38Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#42a4):

Completely untested, but try adding the following into timers.c:

```

BaseType_t xTimerIsTimerActiveFromISR( TimerHandle_t xTimer )
{
BaseType_t xTimerIsInActiveList;
Timer_t *pxTimer = ( Timer_t * ) xTimer;
UBaseType_t uxSavedInterruptStatus;

  /* Is the timer in the list of active timers? */
  uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
  {
    /* Checking to see if it is in the NULL list in effect checks to see if
    it is referenced from either the current or the overflow timer lists in
    one go, but the logic has to be reversed, hence the '!'. */
    xTimerIsInActiveList = ( BaseType_t ) !( listIS_CONTAINED_WITHIN( NULL, &( pxTimer->xTimerListItem ) ) );
  }
  portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );

  return xTimerIsInActiveList;
}

```

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 15, 2014, 3:43pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/16 "2014-11-15T15:43:12Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Saturday, November 15, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#661f):

ah sh…  
Just realized, that this didn’t solve problem.  
During the change to new FreeRTOS-Version i expirienced a bluescreen on PC.  
This bluescreen somehow, compromised my projectsettings so that some Symbols  
were resetted. I needed this symbols so simulate a proper CAN-Communication, so the code having the problem, wasn’t even executed during my test with the new version of FreeRTOS.

The lock still happens with the new and the old version of FreeRTOS, altough, with the newer Version it even ran 10 Minutes without a mistake, just to freeze then.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 17, 2014, 2:37pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/17 "2014-11-17T14:37:12Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Monday, November 17, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#87df):

Hi again!

After some additional testing, i think that i’ve tracked down the problem to the priority switching of a mutex-owner due to a blocked mutex.

Crash occures with following behaviour:

Task 1 with priority 2.  
Task 2 with priority 3.  
TimerTask with priority 3.

01: Task 1 takes **TxMutex**.  
02: Task 1 starts Timer 5ms.  
03: Task 1 is blocked in **xQueueReceive(ResponseQueue)**, waiting for message from Task 2.  
04: Task 2 wants to take **TxMutex** –\> Is blocked  
05: Task 1 then should be set to priority 3, because he own’s **TxMutex**  
06: TimerTask gives **TxMutex**  
07: Task 2 finally takes **TxMutex**  
08: Task 2 starts TimerTask 5ms  
09: Task 2 sends into **ResponseQueue** of Task 1  
10: TimerTask gives **TxMutex**  
11: Task 1 receives Message from Task 2 in **ResponseQueue**  
12: Task 1 does some work…  
13: Task 1 calls **xQueueReceive(ResponseQueue)** again  
14: Task 1 crashes in list.c file due do corrupt list.

After i detected this, I changed the mutex to a semaphore, to get  
the priority change out of list. Crash disappeared, everything is  
working fine right now.

Might there be a problem with the priority-change? When a mutex-owner  
is blocked and it’s priority is changed or something like that?

Additional Info to the previous post: It seem’s that with newest version, the  
problem is also fixed. Couldn’t reproduce the crash with newest version.

Best regards,  
David

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 17, 2014, 3:29pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/18 "2014-11-17T15:29:04Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 17, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#87df/0547):

> 06: TimerTask gives TxMutex

…but the timer task was not the mutex holder.

> Additional Info to the previous post: It seem’s that with newest  
> version, the problem is also fixed. Couldn’t reproduce the crash with newest version.

That is alright then ;o) All the same when I get the chance I will play  
through this scenario to make sure it is safe.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 17, 2014, 3:36pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/19 "2014-11-17T15:36:43Z")

</div>

**[deiti123](https://sourceforge.net/u/deiti123/)** wrote on [Monday, November 17, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#87df/0547/0f2d):

> …but the timer task was not the mutex holder.

Does this mean that a mutex has to be given back only from the task who’s the current owner of the mutex?

I also checked out another scenario where  
01: Task 1 takes **TxMutex**  
02: Task 1 starts Timer 5ms  
were skipped, this also works perfectly (although timertask still give back mutex)

Only difference here, is that there aren’t 2 different tasks who want to take the mutex.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 17, 2014, 3:46pm UTC](https://forums.freertos.org/t/crash-in-vlistinsert-due-to-xvalueofinsertion-is-equal-to-pxnext-xitemvalue/1369/20 "2014-11-17T15:46:53Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 17, 2014](https://sourceforge.net/p/freertos/discussion/382005/thread/3d5acf6c/#87df/0547/0f2d/de21):

I would have to walk through the scenarios in a particular version.  
This was changed recently to allow easier integration with third party  
code (that was fixed, so could not be edited to match our model).

The special case with the mutex is the pointer to the mutex holder.  
This is why, for example, [in the current version] a mutex can be given  
from an interrupt but cannot be taken from an interrupt. Not that it  
would make sense for an interrupt to hold a mutex anyway, but if it were  
to attempt to hold one there would be no persistent ‘mutex holder’.