From: Willy Tarreau <w@1wt.eu>
Date: Tue, 28 Jan 2014 21:48:24 +0000 (+0100)
Subject: BUG/MEDIUM: counters: fix stick-table entry leak when using track-sc2 in connection
X-Git-Tag: v1.5-dev22~17
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e9101695ef354d5e3e17e8e65d224f380aa841e5;p=thirdparty%2Fhaproxy.git

BUG/MEDIUM: counters: fix stick-table entry leak when using track-sc2 in connection

In 1.5-dev19, commit e25c917 ("MEDIUM: counters: add support for tracking
a third counter") introduced the third track counter. However, there was
a hard-coded test in the accept() error path to release only sc0 and sc1.
So it seems that if tracking sc2 at the connection level and deciding to
reject once the track-sc2 has been done, there could be some leaking of
stick-table entries which remain marked used forever, thus which can never
be purged nor expired. There's no memory leak though, it's just that
entries are unexpirable forever.

The simple solution consists in removing the test and always calling
the inline function which iterates over all entries.
---

diff --git a/src/session.c b/src/session.c
index 8241d06998..600d536359 100644
--- a/src/session.c
+++ b/src/session.c
@@ -230,8 +230,7 @@ int session_accept(struct listener *l, int cfd, struct sockaddr_storage *addr)
 	task_free(t);
  out_free_session:
 	p->feconn--;
-	if (s->stkctr[0].entry || s->stkctr[1].entry)
-		session_store_counters(s);
+	session_store_counters(s);
 	pool_free2(pool2_session, s);
  out_free_conn:
 	cli_conn->flags &= ~CO_FL_XPRT_TRACKED;