[
https://issues.apache.org/jira/browse/ZOOKEEPER-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15472620#comment-15472620
]
Hudson commented on ZOOKEEPER-2558:
-----------------------------------
SUCCESS: Integrated in Jenkins build ZooKeeper-trunk #3067 (See
[https://builds.apache.org/job/ZooKeeper-trunk/3067/])
ZOOKEEPER-2558: Potential memory leak in recordio.c (Michael Han via phunt)
(phunt:
[http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1759735])
* (edit) trunk/CHANGES.txt
* (edit) trunk/src/c/src/recordio.c
> 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, 3.6.0
>
> 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)
