lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] f'up: Leaking tcp_ucbs in raw api


From: Steinberg Michael
Subject: [lwip-users] f'up: Leaking tcp_ucbs in raw api
Date: Tue, 29 Aug 2017 14:44:09 +0000

Hello,

Here's a bit more context to my problem. When I call tcp_close in reaction to 
being handed a NULL pbuf ptr in the receive-callback, this is what happens 
inside file  "tcp.c": Eventually tcp_close_shutdown is called with the tcp_pcb 
in state CLOSE_WAIT. The "Not all data received by application ... " branch is 
taken and then on line 279 the pcb is removed from the active pcb list. At this 
point ALL lists (eg. tcp_bound_pcbs, tcp_listen_pcbs, tcp_active_pcbs, 
tcp_tw_pcbs) are empty. Then since I called tcp_close from within the recv 
handler, the branch on ln. 288 is taken, which merely sets a flag so the pcb is 
deleted later-on. But since the pcb is in no list of lwip anymore that I'm 
aware of, how would that deferred delete even work?

Maybe you can spot my misconception better with these details?

Kind regards, Michael


-----Ursprüngliche Nachricht-----
Von: lwip-users [mailto:address@hidden Im Auftrag von Steinberg Michael
Gesendet: Dienstag, 29. August 2017 11:57
An: 'address@hidden' <address@hidden>
Betreff: [lwip-users] Leaking tcp_ucbs in raw api

Hi all,

After a rather long  timeout with lwip I'm trying to get tcp working on top of 
the raw api. I'm currently experiencing leaking tcp_ucbs that I cannot find a 
solution for.
There are two cases where I call tcp_close on tcp pcbs:

a) Inside the receive callback if the passed pbuf pointer is NULL: connection 
pcb
b) Inside a successful accept callback: listening pcb.

As you can see I'm trying to have at most one active TCP connection at any 
point in time.
What happens when I call tcp_close is that the pcb's flags receive TF_CLOSED. 
But they are subsequently never actually freed internally inside lwip and after 
a few connections I'm running out of tcp pcbs. Looking at tcpip_input it seems 
to me that I would actually need to receive a message on a flagged-closed 
tcp_ucb for the chance of being freed. But this does not happen in my case.

I'm running on version STABLE-2.0.2. Can anybody help me sort this out? How do 
I really have to close tcp_ucbs so they really get freed rather than flagged as 
closed only? 

Kind regards, Michael


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

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