lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #59349] TCP Memory Issues


From: Dave Smith
Subject: [lwip-devel] [bug #59349] TCP Memory Issues
Date: Mon, 26 Oct 2020 06:39:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

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

                 Summary: TCP Memory Issues
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dave_smith_inst
            Submitted on: Mon 26 Oct 2020 10:39:03 AM UTC
                Category: TCP
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head

    _______________________________________________________

Details:

Hello LwIP dev team,

I am using the LwIP 2.1.2 version on the TI ARM M4 chipsets (LM3S and TM4C).
This is running with no OS where the TCP is used to send large quantities of
data. I have attached my LwIP trace below which shows the issue.

In this trace, the connection poll function is called, where I take my ring
buffer which holds the data to be transmitted, and loop over to create the
tcp_write calls for up to 1388 bytes at a time. From here you can see the
following segments are queued,
tcp_write: queueing 76191:77579
tcp_write: queueing 77579:78967
tcp_write: queueing 78967:80355

however, when tcp_output is called, only the final segment is output.

tcp_output_segment: 78967:80355

I have added some additional tracing inside memp.c (memp_malloc: and
memp_free:) to log when TCP_segments are allocated and deallocated. Because
the tcp_segs are never output, the memory is never deallocated and thus the
system will eventually fail once all the tcp segs have been allocated.

The TCP still recognizes there are packets in the queue to be sent as the
trace line '_tcp_buff_space: 1388, queue len: 6' reveals after the fault
occurs.

This is a call from my own tcp_api where the code first checks there is space
in the TCP_SEND_BUF and TCP_QUEUE_LEN prior to making any calls to tcp_write.

1603543340,tcp_output: nothing to send (00000000)
1603543340,GEN: Total bytes read: 62460, Offset: 62460, Data Read: 4164
1603543341,TCP: conn_poll
1603543341,TCP: tcp_chunks
1603543341,TCP: _tcp_buff_space: 5552, queue len: 0
1603543341,TCP: tcp_write. index: 0, len: 1388
1603543341,tcp_write(pcb=200025d4, data=2000c134, len=1388, apiflags=2)
1603543341,memp_malloc: TCP_SEG size: 20, number: 8, base: 20002778, free:
20002804
1603543341,memp_malloc: avail: 8, used: 0, max: 3, err: 0
1603543341,tcp_write: queueing 76191:77579
1603543341,TCP: _tcp_buff_space: 4164, queue len: 2
1603543341,TCP: tcp_write. index: 1388, len: 1388
1603543341,tcp_write(pcb=200025d4, data=2000c6a0, len=1388, apiflags=2)
1603543341,memp_malloc: TCP_SEG size: 20, number: 8, base: 20002778, free:
200027DC
1603543341,memp_malloc: avail: 8, used: 1, max: 3, err: 0
1603543341,tcp_write: queueing 77579:78967
1603543341,TCP: _tcp_buff_space: 2776, queue len: 4
1603543341,TCP: tcp_write. index: 2776, len: 1388
1603543341,tcp_write(pcb=200025d4, data=2000cc0c, len=1388, apiflags=2)
1603543341,memp_malloc: TCP_SEG size: 20, number: 8, base: 20002778, free:
20002804
1603543341,memp_malloc: avail: 8, used: 2, max: 3, err: 0
1603543341,tcp_write: queueing 78967:80355
1603543341,TCP: tcp_chunks END
1603543341,TCP: conn_poll END
1603543341,tcp_output_segment: 78967:80355
1603543341,tcp_output: nothing to send (00000000)

1603543341,TCP
1603543341,     xmit: 4700
1603543341,     recv: 2300
1603543341,     fw: 0
1603543341,     drop: 0
1603543341,     chkerr: 0
1603543341,     lenerr: 0
1603543341,     memerr: 0
1603543341,     rterr: 0
1603543341,     proterr: 0
1603543341,     opterr: 0
1603543341,     err: 0
1603543341,     cachehit: 2294

1603543341,MEM HEAP
1603543341,     avail: 5840
1603543341,     used: 2684
1603543341,     max: 2752
1603543341,     err: 0

1603543341,MEM UDP_PCB
1603543341,     avail: 4
1603543341,     used: 2
1603543341,     max: 2
1603543341,     err: 0

1603543341,MEM TCP_PCB
1603543341,     avail: 4
1603543341,     used: 1
1603543341,     max: 2
1603543341,     err: 0

1603543341,MEM TCP_PCB_LISTEN
1603543341,     avail: 8
1603543341,     used: 1
1603543341,     max: 1
1603543341,     err: 0

1603543341,MEM TCP_SEG
1603543341,     avail: 8
1603543341,     used: 3
1603543341,     max: 3
1603543341,     err: 0

1603543341,MEM SYS_TIMEOUT
1603543341,     avail: 8
1603543341,     used: 5
1603543341,     max: 5
1603543341,     err: 0

1603543341,MEM PBUF_REF/ROM
1603543341,     avail: 8
1603543341,     used: 3
1603543341,     max: 3
1603543341,     err: 0

1603543341,MEM PBUF_POOL
1603543341,     avail: 14
1603543341,     used: 0
1603543341,     max: 4
1603543341,     err: 0
1603543341,TCP: conn_poll
1603543341,TCP: tcp_chunks
1603543341,TCP: _tcp_buff_space: 1388, queue len: 6
1603543341,TCP: tcp_chunks END
1603543341,TCP: conn_poll END
1603543341,tcp_output: nothing to send (00000000)
1603543341,TCP: conn_poll
1603543341,TCP: tcp_chunks
1603543341,TCP: _tcp_buff_space: 1388, queue len: 6
1603543341,TCP: tcp_chunks END
1603543341,TCP: conn_poll END
1603543341,tcp_output: nothing to send (00000000)
1603543341,TCP: conn_poll
1603543341,TCP: tcp_chunks
1603543341,TCP: _tcp_buff_space: 1388, queue len: 6
1603543341,TCP: tcp_chunks END
1603543341,TCP: conn_poll END
1603543342,TCP: conn_poll
1603543342,TCP: tcp_chunks
1603543342,TCP: _tcp_buff_space: 1388, queue len: 6
1603543342,TCP: tcp_chunks END
1603543342,TCP: conn_poll END
1603543342,TCP: conn_poll
1603543342,TCP: tcp_chunks
1603543342,TCP: _tcp_buff_space: 1388, queue len: 6
1603543342,TCP: tcp_chunks END
1603543342,TCP: conn_poll END
1603543342,TCP: conn_poll
1603543342,TCP: tcp_chunks
1603543342,TCP: _tcp_buff_space: 1388, queue len: 6
1603543342,TCP: tcp_chunks END
1603543342,TCP: conn_poll END

If you would like anymore info then please let me know. I can easily recreate
this issue so if you would like any additional traces please feel free to
ask!

Thank you,

Dave Smith




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]