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:
parent
758e0818c3
commit
0e6f968ee3
@ -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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user