threads / patch / 19354

patchFix minor memory leak in init-db

Subject: [PATCH] Fix minor memory leak in init-db

## tl;dr

5 messages between May 14, 2009 and May 17, 2009. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Ammon Riley· May 14, 2009, 22:22 UTC · lore

There was an xmalloc() for path, but I didn't see a corresponding free(). Does it happen somewhere else that I'm not expecting?

Signed-off-by: Ammon Riley <ammon.riley@gmail.com>
---
 builtin-init-db.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Show changes to builtin-init-db.c +2 −0

diff --git a/builtin-init-db.c b/builtin-init-db.c
index d1fa12a..6969987 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -308,6 +308,8 @@ int init_db(const char *template_dir, unsigned int flags)
 	strcpy(path+len, "/info");
 	safe_create_dir(path, 1);

+	free(path);
+
 	if (shared_repository) {
 		char buf[10];
 		/* We do not spell "group" and such, so that

-- 
1.6.3.1.9.g95405b.dirty

Junio C Hamano· May 16, 2009, 19:56 UTC · re: Ammon Riley · lore

Re: [PATCH] Fix minor memory leak in init-db

Ammon Riley <ammon.riley@gmail.com> writes:

> There was an xmalloc() for path, but I didn't see a corresponding free().
> Does it happen somewhere else that I'm not expecting?

It implicitly happens in exit() in git.c:handle_internal_command() after cmd_init_db() returns the control to it.

Ammon Riley· May 17, 2009, 04:07 UTC · re: Junio C Hamano · lore

Re: [PATCH] Fix minor memory leak in init-db

On Sat, May 16, 2009 at 12:56 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> Ammon Riley <ammon.riley@gmail.com> writes:
>
>> There was an xmalloc() for path, but I didn't see a corresponding free().
>> Does it happen somewhere else that I'm not expecting?
>
> It implicitly happens in exit() in git.c:handle_internal_command()
> after cmd_init_db() returns the control to it.

Ah. Naturally. :)

So if I were to write a long-lived application (such as a custom UI) that links to libgit, and bypasses those functions to call init_db() (and other functions) directly, all those implicit free-on-exit() turn into memory leaks.

Cheers, Ammon

Junio C Hamano· May 17, 2009, 05:13 UTC · re: Ammon Riley · lore

Re: [PATCH] Fix minor memory leak in init-db

Ammon Riley <ammon.riley@gmail.com> writes:

Show 15 quoted lines

> On Sat, May 16, 2009 at 12:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Ammon Riley <ammon.riley@gmail.com> writes:
>>
>>> There was an xmalloc() for path, but I didn't see a corresponding free().
>>> Does it happen somewhere else that I'm not expecting?
>>
>> It implicitly happens in exit() in git.c:handle_internal_command()
>> after cmd_init_db() returns the control to it.
>
> Ah. Naturally. :)
>
> So if I were to write a long-lived application (such as a custom UI) that
> links to libgit, and bypasses those functions to call init_db() (and other
> functions) directly, all those implicit free-on-exit() turn into memory
> leaks.

Correct, and there are other much larger issues to worry about.

That's why there is a separate libgit2 effort in progress.

Ammon Riley· May 17, 2009, 16:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] Fix minor memory leak in init-db

On Sat, May 16, 2009 at 10:13 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Ammon Riley <ammon.riley@gmail.com> writes:
>
>> On Sat, May 16, 2009 at 12:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Ammon Riley <ammon.riley@gmail.com> writes:
>>>
>>>> There was an xmalloc() for path, but I didn't see a corresponding free().
>>>> Does it happen somewhere else that I'm not expecting?
>>>
>>> It implicitly happens in exit() in git.c:handle_internal_command()
>>> after cmd_init_db() returns the control to it.
>>
>> Ah. Naturally. :)
>>
>> So if I were to write a long-lived application (such as a custom UI) that
>> links to libgit, and bypasses those functions to call init_db() (and other
>> functions) directly, all those implicit free-on-exit() turn into memory
>> leaks.
>
> Correct, and there are other much larger issues to worry about.
>
> That's why there is a separate libgit2 effort in progress.

Okay, cool! I wasn't aware of that -- I'll take a look at it. In the meantime, are small patches for this type of issue welcome if I run across others, or would you prefer I let them lie?

Cheers, Ammon