[lwip-users] Is this a memory fragmentation problem

[Keith Rubow]

I am using lwip 2.0.3, NO_SYS=1, callback api. I have an application 
that works for a while, then gets into a mode where it seems to be 
unable to send and data over a TCP connection. I am listening for 
incoming connections on two different ports. One port will accept only 1 
connection at a time, the other can accept up to 5 connections. I have 
the following on my lwipopts.h file:
#define MEMP_NUM_TCP_PCB_LISTEN   2
#define MEMP_NUM_TCP_PCB   6
#define TCP_WND (2*TCP_MSS)
I am using the defaults in opt.h for PBUF_POOL_SIZE (16) and MEM_SIZE 
(1600).

For a while, everything works fine. Then suddenly everything seems to 
break down and my application cannot send data. Further testing showed 
that my application could send only very short blocks of data at a time 
(14 bytes or less). Trying to send 15 bytes or more would not work.

My code for sending data is as follows (simplified):
if (tcp_sndbuf(mypcb) >= mydatasize) {
    if (tcp_write(mypcb, mybuffer, mydatasize, TCP_WRITE_FLAG_COPY) == 
ERR_OK) {
        tcp_output(mypcb);
    }
}

The data I send is never more than 128 bytes (or 56 bytes on the port 
that accepts 5 connections). I have determined that when my application 
fails I have mydatasize=128, and tcp_sndbuf() returns 1072, but then 
tcp_write() fails. I have not enabled LWIP_STATS yet (but I probably 
will later today).

I'm sorry I can't tell you what error code is being returned by 
tcp_write(). I need to add more debug code in my program, and it takes 
hours to get it into this failure mode. But it seems strange that 
tcp_sndbuf() tells me I have plenty of space available, but yet I cannot 
write my little 128 byte buffer of data. Could it be that the 1600 byte 
memory pool is becoming so fragmented that lwip cannot allocate a 
sufficiently large block of memory?

Any Ideas would be appreciated. I will try to collect more data to 
localize the problem, but it takes time.

Keith Rubow