Fix a memory leak in socket_listener when using SSL

[phemmer]

This fixes a leak in the socket code (used by socket_listener) for tracking connections. Connections are stored so that they can be closed on plugin shutdown, however in the case of SSL sockets, the underlying net.Conn for the TCP connection was stored, but when a socket shut down on its own, it was looked up by it's tls net.Conn handle, which didn't match, resulting in the connection list growing endlessly.

This fix addresses the issue by switching to using context for shutdown notification, and dropping the need for connection tracking. socket_listener predated context being in the minimum supported version, and context.AfterFunc didn't come around until 6 years later, which is why this approach wasn't used initially.

This change also adds some minor refactoring to deduplicate some relevant code.

The added test to check for any future memleak issues does unfortunately take a little while to run (2.2s on my workstation). It basically creates/destroys a few thousand connections and checks the memory profile for allocations. When the number of objects on the heap grows by more than half the number of loops in the test, the test fails. There is inherent noise in the number of objects in the heap, so it requires a few thousand loops. 1000 was not enough to prevent random failures. 2000 seems fine, but I went well above to 5000 for safety. The threshold could possibly be increased to 75% or so, allowing the loop count to be lowered, but this may reduce the safety margin.

Fixes #15509

Summary

Checklist

• [ ] No AI generated code was used in this PR

Related issues

resolves #

[srebhan]

@phemmer please tick the"no AI" box if you didn't use AI! ;-)

[phemmer]

@phemmer please tick the"no AI" box if you didn't use AI! ;-)

I can't say that I didn't. I don't know that I did for sure, but it's very likely at least some statements came from Github CoPilot. And while I'm not trying to be a jerk about it, I honestly don't feel like rewriting this whole thing from scratch. So given that I now see it goes against your contribution rules, I see no option but to close the PR. I would say you're welcome to use the PR as inspiration for your own solution, but given that I don't recall which (if any) parts were generated, I don't think that would be a good idea.

[telegraf-tiger[bot]]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip. Downloads for additional architectures and packages are available below.

:relaxed: This pull request doesn't significantly change the Telegraf binary size (less than 1%)

:package: Click here to get additional PR build artifacts

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz