]> git.kaiwu.me - haproxy.git/commit
MINOR: stconn: prefer to replace endpoints rather than detaching them
authorWilly Tarreau <w@1wt.eu>
Fri, 4 Sep 2026 10:07:55 +0000 (12:07 +0200)
committerWilly Tarreau <w@1wt.eu>
Fri, 4 Sep 2026 13:12:54 +0000 (15:12 +0200)
commit75e93d71dd3ecb8411080b62df96b5479b0570ac
treecb23ad989beaf012ba8e4425356f383f0bccf8ba
parentc044fdbf47da904d0544a5eb43f8e80d5f502bef
MINOR: stconn: prefer to replace endpoints rather than detaching them

sc_detach_endp() is used to detach an endpoint, after which we either
assign a new one or completely release the object. Thus, it is guaranteed
that an stconn may not be found with no endpoint. However this is true in
the regular code flow, not at the signal level. And running "show threads"
during a retry, or triggering watchdog warnings on it can witness such a
stream executing instructions at the end of sc_detach_endp() before the
new endp is assigned, causing segfaults during dumps as described in
github issue #3490.

The new sedesc is allocated before releasing the old one, so we have
everything to perform a replacement. For this reason, sc_detach_endp()
was now replaced with sc_replace_endp(). It takes an optional new
endpoint to assign. When detaching, we just continue to pass NULL.
But when switching, we pass the newly allocated one and an external
observer may never see a NULL in the variable.

Note that we don't use atomics here (not really needed, and not enabled
without threads anyway). No failure was observed with millions of thread
dumps and millions of dumped streams. But if it were to still happen on
some specific archs, it would be fine to switch to an atomic store (it
was tested and works as well).

This may have to be backported to a few stable versions if it helps
improve the overall reliability during dumps, but let's wait a bit
first.
src/stconn.c