comment #19:

> Still, it raises the question in which instances RST is being used in other IP layers (lwIP counterparts), if implemented at all.

RST is a feature of TCP. Not of IP, nor of UDP, etc.

comment #17:

> Brendan, I hope we can agree on the following:
> A memory leak is 1. Memory allocation that is never freed. 2. It is not done intentionally (permanent allocation on the heap)
> This means that allocations being kept beyond regular use and only returned after some sort of timeout is not a leak.

I appreciate the distinction you're making here. I may have conflated a detail here or there, as I troubleshot a few network-related issues in quick succession.

OTOH, if an application is periodically making (or attempting to make) connections, and the allocated heap memory for those connections are persisting for a long time beyond what's expected, one could wind up with similar results to a memory leak. If the total available heap is less than the steady state excess allocation that would occur (between connections/allocations and timeouts), then the resulting behavior would look like a memory leak, right?

Is it possible that was the case in your stress testing?

> Somewhere I read that whenever a new PCB is needed it is allocated permanently never to be freed and used over and over again. This is not a memory leak either.

IDK if that is the case, but I would agree (not a leak), hypothetically.

> I managed to stress-test my system over a long period of time and remaining heap space kept decreasing. That is a memory leak. I might be able to make some more testing this coming fall.

Should we table this part of discussion until then?

Should discussion of my issue and patch continue here on this bug report? Since it may or may not be the same as OP.

> I can  perfectly understand your point wanting to terminate the connection altogether instantly. Probably you have secondary effects from the presence of the zombie connection.

Indeed.

> I don't know a lot about the TCP protocol (particularly the difference between FIN and RST), but it seems to me that once you want the connection to terminate there should be only one single way to do it.

No, a normal graceful termination (w/ FIN/ACK etc) includes a handshake to ensure that both sides of the connection acknowledge. The sockets implementation ensures pending transmissions complete before initiating the termination sequence. The necessary heap remains allocated (on both ends) until it's done, and then are cleaned up at termination.

A hard disconnect doesn't handshake. The peer that wants to disconnect sends a TCP RST and frees its resources right away. The other end may receive that RST and abort/cleanup then; or it may not receive it, and eventually timeout (and cleanup).

> What could be gained by letting the connection hang around for a while?

In normal cases, it is part of a non-blocking implementation. e.g. It allows the application to enqueue its final transmission, and the socket closure.

In hard disconnect cases, for the peer (A) initiating the closure, nothing is to be gained. But on the other end (B), if the RST is not received, (B) can wait to receive something from (A), or timeout.

comment #14:

> It is quite obvious to me that Brendan has not checked the heap for memory leaks, so that part of my bug report is not really addressed.

Yes I had.

I will (attempt to) attach some excerpt outputs from stats_display(), with and without my patch. (If it works, you can) diff them and note the "used:" differences.

> Still I would have tested the linger(0) procedure to see if the cleanup within the lwip layer works better after a sudden physical breakup of the connection. I was pretty convinced at the time that the issue had to be found in that layer.

If you had unsent or unacked data, I believe your setup may have worked w/ just linger(0), w/o my patch.

> Unfortunately I currently don't even have the hardware to test it.
> Besides the problem is rather insidious with only a few bytes being consumed each time it happens. Apparently no one else has come across it during the two years of presence in the bug listing.

(file #56227, file #56228)

It is quite obvious to me that Brendan has not checked the heap for memory leaks, so that part of my bug report is not really addressed.
Still I would have tested the linger(0) procedure to see if the cleanup within the lwip layer works better after a sudden physical breakup of the connection. I was pretty convinced at the time that the issue had to be found in that layer.
Unfortunately I currently don't even have the hardware to test it.
Besides the problem is rather insidious with only a few bytes being consumed each time it happens. Apparently no one else has come across it during the two years of presence in the bug listing.

I proposed a patch:
https://github.com/lwip-tcpip/lwip/pull/35

Maybe this behaviour could be related to bug #61666? Could you try to apply the patch proposed there (e.g diff file #53000)?

I'm not sure I can follow this discussion. However, if you want to abort (send RST), call tcp_abort, not tcp_close.

Stian, I don't follow. The whole reason I started using linger on (+ timeout = 0) is because it was not aborting the socket.

In further testing, I've found that my proposed solution only works when there is neither unsent nor unacked data in the TCP PCB. So for instance if the route between host and server goes down in the middle of an HTTP GET download, and you try to abort as I described in comment #1, lwIP will try to normal close the socket (i.e. client sends a FIN and waits for FIN/ACK).

It's this line of code that makes it behave that way:
https://github.com/lwip-tcpip/lwip/blob/62ac0faad804198e00bbcc70f5ff5927e05a5791/src/api/api_msg.c#L985

Can anyone clarify:
 - Is this lwIP behavior correct? If so, why?
 - How can an application be sure to trigger a TCP RST and immediately free the socket resources when there are no unsent and unacked data?

(... When my application wants to abort and immediately free the socket resources, in this scenario, I think my workaround for the moment may be to add a call to lwip_send() w/ a dummy byte before calling lwip_shutdown() / lwip_close().)

Hi Brendan and thanks for the input

Interesting. It has been a while and I have since migrated the server side to an Raspberry Pi for various reasons.

My memory has faded slightly but I remember that closing the socket actually worked because the number of allowed connections is very limited in the ESP IDF framework and rapidly saturated when client modules were abruptly reset and started up again as a new connection. When the old ones were identified and killed, the only remains were small chunks of memory on the heap that didn't go away after the TCP time-out.

It does seem probable that this memory corresponds to pending socket transfer data, but it should in my view be freed in the "lwip_close(socket)" call.

I would really like to test your approach to see if that stops the module from leaking memory, but currently I have no setup that enables me to do so.

My conclusion is that our cases differ in that I managed to close the identified stalled socket while you didn't. The suggested lingering option may have resolved the leak.

Socket connection stalls when other peer is reset and cannot be reached. Connection only resolves by itself after 2 hours.

When socket is closed by force it leaves behind small chunks on the Heap (0-36 bytes),

Running espressif idf framework and unable to read actual lwIP version in release. Using Mongoose 7.4 layer.

Refer to https://github.com/espressif/esp-idf/issues/8668
for details