[lwip-devel] [bug #62749] Memory leak in tcp_write

[Bill Auerbach]

URL:
  <https://savannah.nongnu.org/bugs/?62749>

                 Summary: Memory leak in tcp_write
                 Project: lwIP - A Lightweight TCP/IP stack
               Submitter: billauerbach
               Submitted: Mon 11 Jul 2022 02:58:43 PM EDT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.1.3


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Mon 11 Jul 2022 02:58:43 PM EDT By: Bill Auerbach <billauerbach>
Platform: Xilinx Zynq 7030 ARM with lwIP RAW API and NO_SYS=1. Not using
LIBC_MALLOC. There are a 8k of pbufs and MEM_SIZE is 128k. The hardware
descriptor RX size was increased to 1k.

On a 1Gb connection at very high burst receive rates seen only connected to a
10Gb switch, tcp_output and/or tcp_write will not release its pbuf mem_alloced
payload. This payload is lost causing an out of memory in tcp_write after many
hours into a run.

Communications entail receiving 1200-1500 packets with a single ~300 byte
payload return. The memory leak is 320 bytes. PC Task Manager shows average
NIC output at 500-700Mbs. This leak doesn't occur at slower speeds.

The rate of packets is crucial. Connections to a 1Gb switch do not show a
problem. When this leak occurs there are no mem stat or link errors (although
hours into the run I've seen mem stats illegal have a count). These errors
occur before that.

I see the leak logging lwip_stats.mem.avail which is slowly growing by 320
bytes. It is program speed related as well.  Running lwip and the BSP in debug
mode doesn't produce the error. At least not within the hour.

I've wondered if we didn't handle the TCP ACK for this packet and it's payload
isn't being freed.

In order to be able to ship a system running at this speed, we are trying to
work around this by not using TCP_WRITE_FLAG_COPY.







    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?62749>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/