After lwip_socket() more than half of the tasks seem to have disappeared

Kernel
1

Hi.
I’m using LwIP and FreeRTOS on STM32F427 and it looks like calling lwip_socket() causes some FreeRTOS data corruption. I’m using Atollic TrueStudio/ST-link, and when I single-step over lwip_socket, more than half of the tasks disappear from the FreeRTOS task list.

The LwIP version is 2.1.2, and I think the FreeRTOS version is 10.0.0.
What is it that might got corrupted? And any suggestions about what might cause that?

2

Where did the lwIP integration come from?

I think there are a lot of things that could cause this, from an invalid linker script, to an invalid heap manager, to invalid MAC driver integration. The good news is it sounds like the problem is very repeatable, so I would recommend having the memory viewed in the debugger when you step into the function you know is causing the problem, then continue stepping over/into function until you see the memory get corrupted - then you should be able to determine the offending line of code.

3

Thanks for response. That was my plan - but what memory region to watch? Where are the task lists? At least something there seems to get corrupted.

4

Put a watch on “pxCurrentTcb”. This gives the address to the task control block of the current task.
Then put breakpoints in relevant tasks and once they are hit, inspect pxCurrentTcb to see where the tasks are located.

5

Thanks. That might give me some idea where to start digging deeper.

6

Task lists are at the top of tasks.c, would give you link but I’m not at my computer currently. However when you said the tasks disappeared I assumed that was what you were looking at already - so can you explain more about what you mean by tasks disappearing
and how you are determining they have disappeared?

7

The tasks suddenly disappear from the Atollic’s FreeRTOS task list, so I thought maybe something overwrites the lists so that Atollic’s debugger doesn’t find them anymore. More than 10 tasks disappear at once. I suppose that the debugger reads the lists via SWD to find the PCBs.

8

Ahh, it was only the task that called the lwip_socket(). It needed a 4 times bigger stack than it had. That probably overwrote some smaller PCBs.