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>

diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
index 242c594646d1f5efc5022a936a636b2fe07ca36e..bc4571938cc1dbff2bf118589cb841714ec41aec 100644 (file)
--- a/builtin/fsmonitor--daemon.c
+++ b/builtin/fsmonitor--daemon.c
@@ -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);