I recently encountered a bug in the handling of tasks. A consequence of the bug causes ‘pxItemToRemove->pvContainer’ to be NULL in vListRemove(). I can detect the problem by putting a test for ‘pxItemToRemove->pvContainer == NULL’ in that function. The source of the bug is subtle, but I will try to describe the situation. ARM platform. Several tasks exist, including an idle task. The tasks that cause the problem loop around doing some work and then call vTaskSuspend(NULL). An interrupt is used to get the task going again, via xTaskResumeFromISR(). In my case, there are 2 tasks doing this, each has its own interrupt for resuming. The ‘work’ that the tasks perform include using a semaphore to lock/unlock access to a resource. So the task may be suspended two ways 1) at the vTaskSuspend(NULL), and 2) waiting for the semaphore. The first does not have an ‘Event’ associated with it, but the second does (involving xPendingReadyList, and xEventListItem). The problem appears to be generated if the task is suspended on the semaphore, with event, but the interrupt triggers a resume. In my case, the interrupt occurs frequently, so it may happen during the suspend for the semaphore lock. There is nothing in xTaskResumeFromISR() that checks if the task is suspended waiting on an event. Since the task is suspended, waiting for an event, I believe the ISR resume should be ignored… the event has not occured. The following is my solution to accomplish that. In xTaskResumeFromISR() change: if( listIS_CONTAINED_WITHIN( &xPendingReadyList, &( pxTCB->xEventListItem ) ) != pdTRUE ) to: if(( listIS_CONTAINED_WITHIN( &xPendingReadyList, &( pxTCB->xEventListItem ) ) != pdTRUE )                && (pxTCB->xEventListItem.pvContainer == NULL) ) This has solved my current problem with the NULL pointer getting into vListRemove(), but I have to wonder if this is correct? Dan Searles

I think this is related to your previous post regarding the indefinite suspension mechanism (a new thing) – where the task is actually held in the suspended list rather than the event list should it be waiting indefinitely for an event. There is a new release to be made in the next couple of days, so I will fix. Thanks, and regards.

I think I also have a similar problem as Dan. I have a task that is sending data to the UART and then pausing (waiting on a semaphore) until a character is received from the UART to resume printing. However, the when the semaphore is signaled (from the UART Rx task) the Tx task will not resume. I THINK I explained that correctly, but I haven’t dug into that issue yet since I’ve been resolving my printf()-related aborts. Darrik

I think it may be different as I had that fix in while tracking down the NULL pointer problem. So my tasks should have been staying in the suspended list. A task suspended indefinitely and a task suspended on an event both have their GenericItem in the suspended list. Only the task waiting for the event has an EventItem in the PendingReady list. I’m not even sure what would happen if the GenericItem were in one of the Delayed lists.

I think Dans problems relate to the ‘wait indefinitely’ functionality, which was put in quite recently (not quite correctly it seems) following a request from a user.  The problem is probably not related unless you are wanting to wait indefinitely while also using the xTaskResumeFromISR() feature (which incidentally is also a new function following a user request). Regards.

I think I see what you mean. The new part (delay indefinitely) is putting the GenericItem on the suspended list, where as before, it would have gone on a Delayed list. If it were on a delayed list, xTaskResumeFromISR() would not have seen it and wouldn’t resume it. So a proper fix may be a little tricker than what I did. A few more questions are starting to pop up, like should you be able to xTaskResumeFromISR() a task that has a definite wait time? Dan

The intention is that ResumeFromISR() is only used to unsuspend a task that was suspended using vTaskSuspend(), and never a task that was blocked with a timeout on a queue/semphore.  Tasks that are blocked on a queue or semaphore should be woken (within an interrupt) using QueueSendFromISR() or SemaphoreGiveFromISR(). The problem has arisen by placing a task that is blocked on a queue/semaphore into the suspended list (where until recently they would never have been), without updating the ResumeFromISR() function to check that the task is indeed in the Suspended state (as a result of a call to TaskSuspend()), and not in the Blocked state (as a result of a call to a queue or semaphore function with infinite block time). This is definitely an error, but in most cases people have got away from it because their tasks enter either the Suspended or Blocked states, not both.  The scenario you described in the first message of this post is not one I have personally encountered. I think the solution you suggested works, but I need more time to consider it, as per: portBASE_TYPE xTaskResumeFromISR( xTaskHandle pxTaskToResume ) { portBASE_TYPE xYieldRequired = pdFALSE; tskTCB *pxTCB; __pxTCB = ( tskTCB * ) pxTaskToResume; __/* Is the task we are attempting to resume actually suspended? */ __if( listIS_CONTAINED_WITHIN( &xSuspendedTaskList, &( pxTCB->xGenericListItem ) ) != pdFALSE ) __{ ____/* Has the task already been resumed from within an ISR? */ ____if( listIS_CONTAINED_WITHIN( &xPendingReadyList, &( pxTCB->xEventListItem ) ) != pdTRUE ) ____{ ______/* Is the task really in the Suspended state, or blocking ______indefinitely on an event? */ ______if( pxTCB->xEventListItem.pvContainer == NULL ) ______{ ________if( uxSchedulerSuspended == ( unsigned portBASE_TYPE ) pdFALSE ) ________{ __________xYieldRequired = ( pxTCB->uxPriority >= pxCurrentTCB->uxPriority ); __________vListRemove(  &( pxTCB->xGenericListItem ) ); __________prvAddTaskToReadyQueue( pxTCB ); ________} ________else ________{ __________/* We cannot access the delayed or ready lists, so will hold this __________task pending until the scheduler is resumed, at which point a __________yield will be preformed if necessary. */ __________vListInsertEnd( ( xList * ) &( xPendingReadyList ), &( pxTCB->xEventListItem ) ); ________} _______} ____} __} __return xYieldRequired; } The same change is probably required in the TaskResume() function too. With respect to the other issue you raised I was thinking along the lines of: portBASE_TYPE xTaskCheckForTimeOut( xTimeOutType *pxTimeOut, portTickType *pxTicksToWait ) { portBASE_TYPE xReturn; __#if INCLUDE_vTaskSuspend == 1 ____/* The task is waiting indefinitely so had not timed out. */ ____if( *pxTicksToWait == portMAX_DELAY ) ____{ ______xReturn = pdFALSE; ____} ____else __#endif __if( ( xNumOfOverflows != pxTimeOut->xOverflowCount ) && ( xTickCount >= pxTimeOut->xTimeOnEntering ) ) __{ ____/* The tick count is greater than the time at which vTaskSetTimeout() ____was called, but has also overflowed since vTaskSetTimeOut() was called. ____It must have wrapped all the way around and gone past us again. This ____passed since vTaskSetTimeout() was called. */ ____xReturn = pdTRUE; __} __else if( ( xTickCount – pxTimeOut->xTimeOnEntering ) < *pxTicksToWait ) __{ ____/* Not a genuine timeout. Adjust parameters for time remaining. */ ____*pxTicksToWait -= ( xTickCount – pxTimeOut->xTimeOnEntering ); ____vTaskSetTimeOutState( pxTimeOut ); ____xReturn = pdFALSE; __} __else __{ ____xReturn = pdTRUE; __} __return xReturn; } Although I don’t like using the preprocessor in that way. Thoughts? Regards.

I see that my solution was wrong… It misses the ERRONEOUS_UNBLOCK case. I currently don’t see another way that doesn’t add a couple more preprocessor tests, making it less clear. Dan

Consider moving the "if( xTicksToWait > 0 ) " test inside xTaskCheckForTimeOut(). Currently it is outside both calls. Dan

I use portMAX_DELAY when I call xSemaphoreTake() from a task to wait for a character from the UART. I looked at my sequence and here is what happens: 1) TASK1 becomes active and sends data to UART 2) TASK1 pauses by waiting on a semaphore (xSemaphoreTake()) 3) Rx IRQ on UART received 4) UART ISR actually sends the data to TASK1 via xQueueSendFromISR() 5) TASK1 never wakes up (I assume it won’t because it is waiting for the semaphore before it resumes) So, my problem is that I am using the same task. I’ll have to see what to do about that. Darrik

Files under SVN have been updated, but not yet fully tested (which will be done prior to release). Regards.

Richard, I’ve added them in the work that I’m doing – of course I need to get the port working – but I’ll let you know if I see anything else otherwise. Regards, John W.