FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2015 Threads] BUG found in FreeRTOS KernelPosted by kristofmulier on December 21, 2015 I have found a bug in the following function (from the "list.c" file in the Kernel):
~~~~
void vListInsertEnd(Listt * const pxList, ListItemt * const pxNewListItem)
{
ListItem_t * const pxIndex = pxList->pxIndex;
/*-----------------------------------------------*/
/* Integrity checks not used, code removed. */
/*-----------------------------------------------*/
/* Insert a new list item into pxList, but rather than sort the list,
make the new list item the last item to be removed by a call to
listGET_OWNER_OF_NEXT_ENTRY(). */
pxNewListItem->pxNext = pxIndex;
pxNewListItem->pxPrevious = pxIndex->pxPrevious;
/* Only used during decision coverage testing. */
mtCOVERAGE_TEST_DELAY();
pxIndex->pxPrevious->pxNext = pxNewListItem;
pxIndex->pxPrevious = pxNewListItem;
/* Remember which list the item is in. */
pxNewListItem->pvContainer = (void *) pxList;
(pxList->uxNumberOfItems)++;
/* BUG FOUND */
/* The documentation for this function mentions: "Placing */
/* an item in a list using vListInsertEnd(..) effectively */
/* places the item in the list position pointed to by pvIndex." */
/* I believe there are two bugs here: */
/* (1) The correct field name is not "pvIndex" but "pxIndex" */
/* (that's a documentation bug, so not really a big deal) */
/* (2) The pxList->pxIndex does not point to the NewListItem! */
/* The following code line was forgotten: */
pxList->pxIndex = pxNewListItem;
}
~~~~
Did anyone experience this bug?
Kind greetings,
Kristof Mulier
Project Engineer Mechatronics,
Sirris - Heverlee (Belgium)
BUG found in FreeRTOS KernelPosted by rtel on December 21, 2015 I understand your point that the comments in the code are no longer correct, but it is otherwise not clear to me - have you found something in the code that could either potentially mis-behave or potentially crash? If so, please state clearly what it is so it can be assessed.
By mis-behave I mean result in an incorrect task being selected, or other such incorrect behaviour?
Regards.
BUG found in FreeRTOS KernelPosted by kristofmulier on December 21, 2015 Thank you very much for your quick reply :-)
No, I did not see a misbehaviour. But I just figured out that the documentation mentions:
~~~~
/* The "pxIndex" from the Listt will point to the newly inserted ListItemt , such that every other item within the list will be returned by listGETOWNEROFNEXTENTRY(..) before the pxIndex parameter again points to the item being inserted. */
~~~~
Indeed, when you call the macro "listGETOWNEROFNEXTENTRY(..)", the pxIndex parameter from the list gets incremented first, such that it points to the "next entry" from which the owner is returned. So the documentation above makes perfectly sense.
Unfortunately, the documentation doesn't correspond with the actual behaviour of the "vListInsertEnd(..)" function. This is because the following code line is forgotten (or at least, it looks to me like the developer forgot this line of code to update the pxIndex):
~~~~
pxList->pxIndex = pxNewListItem;
~~~~
That's all :-)
One more question: I noticed that some parts of the documentation mention the List_t to be in descending order, whereas other parts of the documentation state that it's ascending order. So I'm a bit confused.
From the function:
~~~~
vListInsert( Listt * const pxList, ListItemt * const pxNewListItem )
~~~~
I conclude that it is ascending order (from small to large). Is my conclusion correct?
Kind greetings :-)
BUG found in FreeRTOS KernelPosted by edwards3 on December 21, 2015 I think the following quick test shows the expected behavior?
~~~~
ListItemt item1 = { 1, NULL, NULL, 1, NULL };
ListItemt item2 = { 2, NULL, NULL, 2, NULL };
ListItemt item3 = { 3, NULL, NULL, 3, NULL };
ListItemt item4 = { 0, NULL, NULL, 0, NULL };
List_t list;
void *result;
int main( void )
{
vListInitialise(&list);
vListInsert(&list, &item1);
vListInsert(&list, &item2);
vListInsert(&list, &item3);
vListInsert(&list, &item4);
// vListInsert() used, so expect to receive in item value order.
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 0); // << 0 first
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 1);
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 2);
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 3);
vListInitialise(&list);
vListInsert(&list, &item1);
vListInsert(&list, &item2);
vListInsert(&list, &item3);
vListInsertEnd(&list, &item4);
// vListInsertEnd() used, so expect to receive 0 last.
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 1);
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 2);
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 3);
listGET_OWNER_OF_NEXT_ENTRY(result, &list);
configASSERT((int)result == 0); // << 0 last
~~~~
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|