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>
Paul Tarjan committed
Apr 15, 2026 at 13:27 UTC
e21be6cd45db554862f40c90b385c1bc465c8335
1 file changed
+2
-3
builtin/fsmonitor--daemon.c
+2
-3
@@ -671,7 +671,7 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
671
const struct fsmonitor_batch *batch;
672
struct fsmonitor_batch *remainder = NULL;
673
intmax_t count = 0, duplicates = 0;
674
- kh_str_t *shown;
674
+ kh_str_t *shown = NULL;
675
int hash_ret;
676
int do_trivial = 0;
677
int do_flush = 0;
@@ -909,8 +909,6 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
909
total_response_len += payload.len;
910
}
911
912
- kh_release_str(shown);
913
-
912
pthread_mutex_lock(&state->main_lock);
913
914
if (token_data->client_ref_count > 0)
@@ -954,6 +952,7 @@ static int do_handle_client(struct fsmonitor_daemon_state *state,
952
trace2_data_intmax("fsmonitor", the_repository, "response/count/duplicates", duplicates);
953
954
cleanup:
955
+ kh_destroy_str(shown);
956
strbuf_release(&response_token);
957
strbuf_release(&requested_token_id);
958
strbuf_release(&payload);