config: use a static lock_file struct
authorJeff King <peff@peff.net>
Tue, 29 Aug 2017 18:58:50 +0000 (14:58 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 6 Sep 2017 03:59:53 +0000 (12:59 +0900)
commitf991761eb8c62cef0355c9abc89ac9d3191ae707
treec33493d4f460d98dee0a78327d491614e3d5ab14
parent3d9c5b5c4461957fbbc0479e037990db04ebb740
config: use a static lock_file struct

When modifying git config, we xcalloc() a struct lock_file
but never free it. This is necessary because the tempfile
code (upon which the locking code is built) requires that
the resulting struct remain valid through the life of the
program. However, it also confuses leak-checkers like
valgrind because only the inner "struct tempfile" is still
reachable; no pointer to the outer lock_file is kept.

Other code paths solve this by using a single static lock
struct. We can do the same here, because we know that we'll
only lock and modify one config file at a time (and
assertions within the lockfile code will ensure that this
remains the case).

That removes a real leak (when we fail to free the struct
after locking fails) as well as removes the valgrind false
positive. It also means that doing N sequential
config-writes will use a constant amount of memory, rather
than leaving stale lock_files for each.

Note that since "lock" is no longer a pointer, it can't be
NULL anymore. But that's OK. We used that feature only to
avoid calling rollback_lock_file() on an already-committed
lock. Since the lockfile code keeps its own "active" flag,
it's a noop to rollback an inactive lock, and we don't have
to worry about this ourselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config.c