summaryrefslogtreecommitdiff
path: root/git.rc
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-08-29 14:58:50 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-09-06 12:59:53 +0900
commitf991761eb8c62cef0355c9abc89ac9d3191ae707 (patch)
treec33493d4f460d98dee0a78327d491614e3d5ab14 /git.rc
parentGit 2.12.4 (diff)
downloadtgif-f991761eb8c62cef0355c9abc89ac9d3191ae707.tar.xz
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>
Diffstat (limited to 'git.rc')
0 files changed, 0 insertions, 0 deletions