[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] [PATCH 0/6] Fix various memory leaks in libgettextpo

From: Daiki Ueno
Subject: Re: [bug-gettext] [PATCH 0/6] Fix various memory leaks in libgettextpo
Date: Wed, 28 Aug 2013 12:16:10 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Hi Alexander,

Alexander Potashev <address@hidden> writes:

> When processing a lot of .po files (like, over 9000) from one process
> using libgettextpo, the memory leaks in the .po parsing code accumulate
> to a few gigabytes, becoming a real problem in this case.
> I tried to fix all the memory leaks that I could detect by running my
> custom application in Valgrind. I mean, some of these leaks do not lead
> to multi-gigabyte memory consumption, but they still should be fixed.

> These patches are now two years old. I have already submitted them
> to the "bug-gettext" mailing list, but nobody have reviewed them
> since then.

Thanks for the patches, but they are not easy to review, because of
inconsistent memory management strategies used in the code.  Probably
it's not a problem of your patches, but the original code.

> Alexander Potashev (6):
>   Copy string from shared buffer
>   Fix memory leak: po_callback_comment_dispatcher does not take
>     ownership of the string passed into it

These two patches look contradicting each other.  If we don't copy the
COMMENT string with the first patch, we don't need to free it in the
second patch, right?

>   Fix memory leak: do not duplicate msgid_plural in message_alloc
>   Fix memory leak: free msgctxt in message_free

These patches too.  Would it be a problem if we always strdup all the
fields of message_ty?

>   Fix memory leak: string_list_append duplicates the string

I'd rather prefer to free after string_list_append rather than adding
the nodup variant of string_list_append.

>   Fix memory leak: free gram_pos.file_name in lex_end()

Looks good.

Daiki Ueno

reply via email to

[Prev in Thread] Current Thread [Next in Thread]