FreeRTOS_select() timeout with uxTaskGetSystemState()

I am running a simple client and server task.

The client task is blocked on FreeRTOS_select() (or should be, since I set xBlockTimeTicks to portMAX_DELAY).

The server calls uxTaskGetSystemState().

When the server then blocks and the client begins to run, FreeRTOS_select() immediately returns 0, implying a timeout (according to the API documentation).

The documentation says that uxTaskGetSystemState() suspends the scheduler for an extended period. Is this the cause of FreeRTOS_socket() timing out despite the argument to block indefinitely?

If I remove the call to uxTaskGetSystemState(), the client behaves as expected (i.e., FreeRTOS_select() blocks until an event on a socket in the socket set).

I can convince myself that this makes sense, but I couldn’t find any explicit documentation, so I wanted some more experienced confirmation before I stopped debugging and moved on to other things.

I’m running kernel V10.1.1 and TCP V2.0.11.


uxTaskGetSystemState() should not change the state of anything and if you have an infinite block time keeping the scheduler suspended for a while should not make any difference: Can you step through the code to see why it is unblocking a task. It may be more likely that there is a memory error or overflow and calling uxTaskGetSystemState() is corrupting something.

Thanks, Richard. With your encouragement, I chased down the problem. It was much simpler than a corruption: FreeRTOS_select() was being called in two places, and I was only adjusting the timeout to portMAX_DELAY in one of them. uxTaskGetSystemState() (and processing the returned state information) was taking just long enough for the second one (with the default timeout of 0.5s) to timeout.