From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
So here comes another bunch of mem leak fixes. While
I consider the first 10 patches a pretty safe bet,
the last 5 hopefully spark a discussion if we want
patches which just clean up before the program ends.
Stefan Beller (15):
read-cache: fix memleak
read-cache: Improve readability
read-cache: free cache entry in add_to_index in case of early return
update-index: fix a memleak
builtin/apply.c: fix a memleak
merge-blobs.c: Fix a memleak
merge-recursive: fix memleaks
http-push: Remove unneeded cleanup
http: release the memory of a http pack request as well
commit.c: fix a memory leak
builtin/check-attr: fix a memleak
builtin/merge-base: fix memleak
builtin/unpack-file: fix a memleak
builtin/cat-file: free memleak
ls-files: fix a memleak
builtin/apply.c | 1 +
builtin/cat-file.c | 1 +
builtin/check-attr.c | 2 ++
builtin/commit.c | 6 ++++--
builtin/ls-files.c | 1 +
builtin/merge-base.c | 1 +
builtin/unpack-file.c | 1 +
builtin/update-index.c | 1 +
http-push.c | 1 -
http.c | 1 +
merge-blobs.c | 4 +++-
merge-recursive.c | 3 +++
read-cache.c | 13 ++++++++-----
13 files changed, 27 insertions(+), 9 deletions(-)
--
2.3.0.81.gc37f363
@@ -703,9 +703,7 @@ int add_to_index(struct index_state *istate, const char *path, struct stat *st,!hashcmp(alias->sha1,ce->sha1)&&ce->ce_mode==alias->ce_mode);-if(pretend)-;-elseif(add_index_entry(istate,ce,add_option))+if(!pretend&&add_index_entry(istate,ce,add_option))returnerror("unable to add %s to index",path);if(verbose&&!was_same)printf("add '%s'\n",path);
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
oldlines is allocated earlier in the function and also freed on the
successful code path.
Signed-off-by: Stefan Beller <redacted>
---
builtin/apply.c | 1 +
1 file changed, 1 insertion(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
preq is NULL as the condition the line before dictates. And the cleanup
function release_http_pack_request is not null pointer safe.
Signed-off-by: Stefan Beller <redacted>
---
http-push.c | 1 -
1 file changed, 1 deletion(-)
@@ -229,7 +229,7 @@ static int commit_index_files(void)staticintlist_paths(structstring_list*list,constchar*with_tree,constchar*prefix,conststructpathspec*pattern){-inti;+inti,ret;char*m;if(!pattern->nr)
@@ -256,7 +256,9 @@ static int list_paths(struct string_list *list, const char *with_tree,item->util=item;/* better a valid pointer than a fake one */}-returnreport_path_error(m,pattern,prefix);+ret=report_path_error(m,pattern,prefix);+free(m);+returnret;}staticvoidadd_remove_files(structstring_list*list)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
Signed-off-by: Stefan Beller <redacted>
---
Notes:
I do not quite recall a discussion about such fixes
when I started doing these fixes like 2 years ago.
As this is a main function of a subcommand the freed
memory is likely to have no impact as the process
is done soon, so then it gets freed by the OS which
is likey to be faster as the OS frees the whole pages
of the process. Also there is no expected memory
shortage as the process is going to be done soon
as opposed to fixing mem leaks early in the process.
An upside of fixes like this one is however to make
code analysis tools produce less noise, so narrowing
down the *real* issue may be easier.
I wonder if we could have a 'weak' free which does
nothing if git is compiled regularly and actually
frees the memory if it is build with a flag to tell
it to do so. This would help finding the real issues
as the noise goes down and it would still be 'fast'
as it could be when compiled for productive use.
On the other hand I don't like to have another
'invented here again' systemcall-ish function as
it would clutter the code and you'd have to remember
to use that weak free.
I dunno.
builtin/check-attr.c | 2 ++
1 file changed, 2 insertions(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
Signed-off-by: Stefan Beller <redacted>
---
Notes:
This is for discussion again,
see 2nd previous patch.
However why do we close the fd when we know
the program ends soon? So let's also
free the memory.
builtin/unpack-file.c | 1 +
1 file changed, 1 insertion(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
Usually when using string lists it looks like:
struct string_list a = STRING_LIST_INIT_NODUP;
// do stuff with a such as
string_list_insert(&a, "test string");
print_string_list(&a, "test prefix");
// Cleaning up works on everything inside the struct, not on the
// struct itself:
string_list_clear(&a);
But as we deal with the pointers to the string lists directly, we also
need to free the actual struct.
Signed-off-by: Stefan Beller <redacted>
---
merge-recursive.c | 3 +++
1 file changed, 3 insertions(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
This frees `ce` would be leaking in the error path.
Additionally a free is moved towards the return. This helps code
readability as we often have this pattern of freeing resources just
before return/exit and not in between the code.
Signed-off-by: Stefan Beller <redacted>
---
read-cache.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
`ce` is allocated in make_cache_entry and should be freed if it is not
used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
will either return `ce` or a new updated cache entry which is allocated
to new memory. In that case we need to free `ce` ourselfs.
Signed-off-by: Stefan Beller <redacted>
---
read-cache.c | 2 ++
1 file changed, 2 insertions(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
The cleanup function is used in 4 places now and it's always safe to
free up the memory as well.
Signed-off-by: Stefan Beller <redacted>
---
http.c | 1 +
1 file changed, 1 insertion(+)
From: Stefan Beller <hidden> Date: 2016-06-15 23:04:14
`old` is not used outside the loop and would get lost
once we reach the goto.
Signed-off-by: Stefan Beller <redacted>
---
builtin/update-index.c | 1 +
1 file changed, 1 insertion(+)