fsmonitor: fix khash memory leak in do_handle_client

The `shown` kh_str_t was freed with kh_release_str() at a point in
the code only reachable in the non-trivial response path.  When the
client receives a trivial response, the code jumps to the `cleanup`
label, skipping the kh_release_str() call entirely and leaking the
hash table.

Fix this by initializing `shown` to NULL and moving the cleanup to the
`cleanup` label using kh_destroy_str(), which is safe to call on NULL.
This ensures the hash table is freed regardless of which code path is
taken.

Signed-off-by: Paul Tarjan <github@paulisageek.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Paul Tarjan
2026-02-26 00:27:14 +00:00
committed by Junio C Hamano
parent 68cb7f9e92
commit 0ecf18fc7e

View File

@@ -671,7 +671,7 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
const struct fsmonitor_batch *batch;
struct fsmonitor_batch *remainder = NULL;
intmax_t count = 0, duplicates = 0;
kh_str_t *shown;
kh_str_t *shown = NULL;
int hash_ret;
int do_trivial = 0;
int do_flush = 0;
@@ -909,8 +909,6 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
total_response_len += payload.len;
}
kh_release_str(shown);
pthread_mutex_lock(&state->main_lock);
if (token_data->client_ref_count > 0)
@@ -954,6 +952,7 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
trace2_data_intmax("fsmonitor", the_repository, "response/count/duplicates", duplicates);
cleanup:
kh_destroy_str(shown);
strbuf_release(&response_token);
strbuf_release(&requested_token_id);
strbuf_release(&payload);