You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Michael Han (JIRA)" <ji...@apache.org> on 2016/09/06 22:59:20 UTC

[jira] [Updated] (ZOOKEEPER-2558) Potential memory leak in recordio.c

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Han updated ZOOKEEPER-2558:
-----------------------------------
    Attachment: ZOOKEEPER-2558.patch

Not a big deal here, but good to stick to better practice. Attach a patch.

> Potential memory leak in recordio.c
> -----------------------------------
>
>                 Key: ZOOKEEPER-2558
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2558
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.4.9, 3.5.2
>            Reporter: Michael Han
>            Assignee: Michael Han
>            Priority: Minor
>             Fix For: 3.4.10, 3.5.3
>
>         Attachments: ZOOKEEPER-2558.patch
>
>
> We have code like this in {{create_buffer_iarchive}} and {{create_buffer_oarchive}}:
> {code}
>     struct iarchive *ia = malloc(sizeof(*ia));
>     struct buff_struct *buff = malloc(sizeof(struct buff_struct));
>     if (!ia) return 0;
>     if (!buff) {
>         free(ia);
>         return 0;
>     }
> {code}
> If first malloc failed but second succeeds, then the memory allocated with second malloc will not get freed when the function returned. One could argue that if first malloc failed the second will also fail (i.e. when system run out of memory), but I could also see the possibility of the opposite (the first malloc failed because heap fragmentation but the second succeeds).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)