BUG/MEDIUM: stktable: fix sc_*(<ctr>) BUG_ON() regression with ctx > 9

As reported in GH #2958, commit 6c9b315 caused a regression with sc_*
fetches and tracked counter id > 9.

As such, the below configuration would cause a BUG_ON() to be triggered:

  global
    log stdout format raw local0
    tune.stick-counters 11

  defaults
    log global
    mode http

  frontend www
    bind *:8080

    acl track_me bool(true)
    http-request set-var(txn.track_var) str("a")
    http-request track-sc10 var(txn.track_var) table rate_table if track_me
    http-request set-var(txn.track_var_rate) sc_gpc_rate(0,10,rate_table)
    http-request return status 200

  backend rate_table
      stick-table type string size 1k expire 5m store gpc_rate(1,1m)

While in 6c9b315 the src_fetch logic was removed from
smp_fetch_sc_stkctr(), num > 9 is indeed not expected anymore as
original num value. But what we didn't consider is that num is effectively
re-assigned for generic sc_* variant.

Thus the BUG_ON() is misplaced as it should only be evaluated for
non-generic fetches. It explains why it triggers with valid configurations

Thanks to GH user @tkjaer for his detailed report and bug analysis

No backport needed, this bug is specific to 3.2.
This commit is contained in:
Aurelien DARRAGON 2025-05-02 16:25:57 +02:00
parent 758e0818c3
commit 0e6f968ee3

View File

@ -3236,8 +3236,8 @@ smp_fetch_sc_stkctr(struct session *sess, struct stream *strm, const struct arg
/* sc_* variant, args[0] = ctr# (mandatory) */
num = args[arg++].data.sint;
}
BUG_ON(num > 9, "unexpected value");
else
BUG_ON(num > 9, "unexpected value");
/* Here, <num> contains the counter number from 0 to 9 for
* the sc[0-9]_ form, or even higher using sc_(num) if needed.