]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/gc: fix crash when running `git maintenance start`
authorPatrick Steinhardt <ps@pks.im>
Thu, 10 Oct 2024 05:33:01 +0000 (07:33 +0200)
committerJunio C Hamano <gitster@pobox.com>
Thu, 10 Oct 2024 17:04:43 +0000 (10:04 -0700)
commitc95547a394a35dc26afa686454086d2db6e51ea4
tree2e9a751d59f44e59a4413c631223bfd5100bb426
parent12dfc2475ce4808df696fb67fc71a66793f78f06
builtin/gc: fix crash when running `git maintenance start`

It was reported on the mailing list that running `git maintenance start`
immediately segfaults starting with b6c3f8e12c (builtin/maintenance: fix
leak in `get_schedule_cmd()`, 2024-09-26). And indeed, this segfault is
trivial to reproduce up to a point where one is scratching their head
why we didn't catch this regression in our test suite.

The root cause of this error is `get_schedule_cmd()`, which does not
populate the `out` parameter in all cases anymore starting with the
mentioned commit. Callers do assume it to always be populated though and
will e.g. call `strvec_split()` on the returned value, which will of
course segfault when the variable is uninitialized.

So why didn't we catch this trivial regression? The reason is that our
tests always set up the "GIT_TEST_MAINT_SCHEDULER" environment variable
via "t/test-lib.sh", which allows us to override the scheduler command
with a custom one so that we don't accidentally modify the developer's
system. But the faulty code where we don't set the `out` parameter will
only get hit in case that environment variable is _not_ set, which is
never the case when executing our tests.

Fix the regression by again unconditionally allocating the value in the
`out` parameter, if provided. Add a test that unsets the environment
variable to catch future regressions in this area.

Reported-by: Shubham Kanodia <shubham.kanodia10@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/gc.c
t/t7900-maintenance.sh