I'm using MCUXpresso 10.2.1 and a custom board based on MK65F2M0 chip. I have a problem on using LwIP: it sometimes crash generating an assert, because of some invalid parameter.
The workflow is:
The board is configured with a main connection using a GPRS modem and an optional second LAN connection
Every about 15 seconds the board connects to a server and sends two types of packets, one smaller and one a little bigger. The bigger one is sended once every 3/4 times typically
Most of the time the server closes the connection (if no operation on the device is requested), but sometimes it can go ahead in the session, exchanging some data (if an operation on the device is requested). In this debug session the server closes the connection every time
The problem is that after a while (5 minutes mean, but sometimes after 20 minutes), the board generates an assertion on releasing a network buffer, because it seems that is trying to free a buffer already freed
Here is a snippet of code:
int sock; int opt; struct sockaddr_in outerdata; int rn;
The problem occurs only when the bigger packet is sent and the first timeout occurred on the recv function (I can see the "WAIT SERVER" message on the debug monitor only once), but it doesn't occurs all the times these conditions are present. The assertion occurs on the pbuf_free() function at the instruction LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);
The image below shows the Wireshark captured session of the smaller packet:
The image below shows the Wireshark captured session of the bigger packet:
The image below shows the Wireshark captured session of the error condition; note that the TCP Retransmission packets are present because the device is stopped on the breakpoint:
I enabled statistics on LwIP and all used resources are below the limits.
I'm not well versed in sockets here, but since you are using sockets,
there shouldn't be application-related pbuf free issues if threading
rules are respected.
Somewhere in your vendor provided code, someone did not play by the
rules. You have an OS, you have a port, you have a driver, you have many
places to search.
You should check for modified code, and threading misuse, that is, all
code for one socket goes in one thread, all low-level code goes in one
I would probably start by tracing the free operation to its caller and
wondering why is it trying to free it or why it has been freed before,
and by whom. Most of the times, when it is not a threading issue, it is
a driver issue.