You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by GitBox <gi...@apache.org> on 2022/06/23 22:40:13 UTC
[GitHub] [trafficserver] cmcfarlen commented on issue #8896: Do some core intercept plugins leak resources on early session termination?
cmcfarlen commented on issue #8896:
URL: https://github.com/apache/trafficserver/issues/8896#issuecomment-1164981659
Looking at the code, it definitely looks like a memory leak is possible if the TS_EVENT_VCONN_WRITE_COMPLETE is not received. I tried to cause this condition with various versions of netcat and then ended up writing a little program that just closes the socket after sending the request. Try as I might, the plugin always saw the TS_EVENT_VCONN_WRITE_COMPLETE event.
Looking at a packet capture, the writes still happen after the FIN is sent:
```1 0.000000 127.0.0.1 127.0.0.1 TCP 68 64978 → 8080 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 TSval=2143886768 TSecr=0 SACK_PERM=1
2 0.000148 127.0.0.1 127.0.0.1 TCP 68 8080 → 64978 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=16344 WS=64 TSval=3383315298 TSecr=2143886768 SACK_PERM=1
3 0.000166 127.0.0.1 127.0.0.1 TCP 56 64978 → 8080 [ACK] Seq=1 Ack=1 Win=408256 Len=0 TSval=2143886768 TSecr=3383315298
4 0.000177 127.0.0.1 127.0.0.1 TCP 56 [TCP Window Update] 8080 → 64978 [ACK] Seq=1 Ack=1 Win=408256 Len=0 TSval=3383315298 TSecr=2143886768
5 0.000210 127.0.0.1 127.0.0.1 HTTP 94 GET /_stats HTTP/1.1
6 0.000218 127.0.0.1 127.0.0.1 TCP 56 64978 → 8080 [FIN, ACK] Seq=39 Ack=1 Win=408256 Len=0 TSval=2143886768 TSecr=3383315298
7 0.000240 127.0.0.1 127.0.0.1 TCP 56 8080 → 64978 [ACK] Seq=1 Ack=39 Win=408256 Len=0 TSval=3383315298 TSecr=2143886768
8 0.000247 127.0.0.1 127.0.0.1 TCP 56 8080 → 64978 [ACK] Seq=1 Ack=40 Win=408256 Len=0 TSval=3383315298 TSecr=2143886768
9 0.008849 127.0.0.1 127.0.0.1 TCP 16388 8080 → 64978 [ACK] Seq=1 Ack=40 Win=408256 Len=16332 TSval=3383315307 TSecr=2143886768 [TCP segment of a reassembled PDU]
10 0.008852 127.0.0.1 127.0.0.1 TCP 12728 8080 → 64978 [PSH, ACK] Seq=16333 Ack=40 Win=408256 Len=12672 TSval=3383315307 TSecr=2143886768 [TCP segment of a reassembled PDU]
11 0.008864 127.0.0.1 127.0.0.1 HTTP 8921 HTTP/1.1 200 OK (text/json)
12 0.008906 127.0.0.1 127.0.0.1 TCP 44 64978 → 8080 [RST] Seq=40 Win=0 Len=0
13 0.008912 127.0.0.1 127.0.0.1 TCP 44 64978 → 8080 [RST] Seq=40 Win=0 Len=0
14 0.008916 127.0.0.1 127.0.0.1 TCP 44 64978 → 8080 [RST] Seq=40 Win=0 Len=0
```
Finally, I observed that the WRITE_COMPLETE event occurs before any outgoing packets hit the wire. So this event is handled after the internal buffer is filled up, not after the bytes are done sending.
I still think it might be possible to cause leaks to occur if other errors happen or perhaps if a send buffer become full, but doesn't happen if the client sends a valid request and then closes the socket.
If you can think of another way to cause the cleanup to be missed, I can try that out as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@trafficserver.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org