[lwip-devel] [bug #62231] LwIP tcp socket stalls when "plug pulled", creates leak when closed

[Brendan McDonnell]

Follow-up Comment #18, bug #62231 (group lwip):

[comment #17 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.


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature