tree 99d685173e74e620346be1e32892b2dddd273b7d
parent d1d3616a9102e5c11ef2081d63ca2acd7cc253da
author Willy Tarreau <w@1wt.eu> 1721121289 +0200
committer Willy Tarreau <w@1wt.eu> 1722257697 +0200
encoding latin1

BUG/MEDIUM: debug/cli: fix "show threads" crashing with low thread counts

The "show threads" command introduced early in the 2.0 dev cycle uses
appctx->st1 to store its context (the number of the next thread to dump).
It goes back to an era where contexts were shared between the various
applets and the CLI's command handlers.

In fact it was already not good by then because st1 could possibly have
APPCTX_CLI_ST1_PAYLOAD (2) in it, that would make the dmup start at
thread 2, though it was extremely unlikely.

When contexts were finally cleaned up and moved to their own storage,
this one was overlooked, maybe due to using st1 instead of st2 like
most others. So it continues to rely on st1, and more recently some
new flags were appended, one of which is APPCTX_CLI_ST1_LASTCMD (16)
and is always there. This results in "show threads" to believe it must
start do dump from thread 16, and if this thread is not present, it can
simply crash the process. A tiny reproducer is:

  global
    nbthread 1
    stats socket /tmp/sock1 level admin mode 666

  $ socat /tmp/sock1 - <<< "show threads"

The fix for modern versions simply consists in assigning a context to
this command from the applet storage. We're using a single int, no need
for a struct, an int* will do it. That's valid till 2.6.

Prior to 2.6, better switch to appctx->ctx.cli.i0 or i1 which are all
properly initialized before the command is executed.

This must be backported to all stable versions.

Thanks to Andjelko Horvat for the report and the reproducer.

(cherry picked from commit e0e2b6613214212332de4cbad2fc06cf4774c1b0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 90494537b272e72f7d46936f0a4bb03146243acb)
[wt: adjusted ctx for 2.9 & tested]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 648af3a5606c33daa4527d463cdbe145b1354830)
Signed-off-by: Willy Tarreau <w@1wt.eu>