[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #52112] Unavoidable hazards when calling tcp_close fro
[lwip-devel] [bug #52112] Unavoidable hazards when calling tcp_close from callback
Mon, 25 Sep 2017 14:39:06 -0400 (EDT)
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36
Summary: Unavoidable hazards when calling tcp_close from
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: abizjak
Submitted on: Mon 25 Sep 2017 06:39:05 PM UTC
Severity: 3 - Normal
Item Group: Faulty Behaviour
Assigned to: None
Discussion Lock: Any
Planned Release: None
lwIP version: git head
Consider an application calling tcp_close from one of the PCB callbacks, where
tcp_close succeeds. In this case the application can either return ERR_ABRT or
not. It seems to me that either way things break.
- If the application does not return ERR_ABRT: There are cases where tcp_close
frees the PCB, but since the callback does not return ERR_ABRT, lwIP will try
to access the freed PCB.
- If the application returns ERR_ABRT: Consider the case where
tcp_close_shutdown called tcp_trigger_input_pcb_close(), having removed the
PCB from tcp_active pcbs but not freeing it. Since the callback returned
ERR_ABRT, tcp_input_delayed_close() is inhibited and the PCB is leaked.
My application is currently taking the second approach and I am seeing leaked
PCBs. I have not proven this is the same leak but I see no other way for a PCB
to be leaked.
Reply to this item at:
Message sent via/by Savannah
- [lwip-devel] [bug #52112] Unavoidable hazards when calling tcp_close from callback,
Ambroz Bizjak <=