[
https://issues.apache.org/jira/browse/ZOOKEEPER-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565961#comment-13565961
]
Deepak Jagtap commented on ZOOKEEPER-1562:
------------------------------------------
Thanks for reviewing this Marshall!
I have verified that valgrind doesn't report any memory leak with my
application.
But somehow I am not managed to successfully run unit tests provided in the
trunk though Hadoop QA reported success for all unit tests. It looks like I am
missing some steps in compile and build.
I am using following steps for compiling, building and running test:
1. svn checkout https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.5/
zookeeper-3.4.5
2. patch -p0 < ZOOKEEPER-1562.patch
2. cd zookeeper-3.4.5
3. ant compile_jute
4. cd zookeeper-3.4.5/src/c
5. autoreconf -if
6. ./configure
7. make
8. cd ../../../zookeeper-3.4.5
9. ant test
On the console I could see many tests failed.
I tried same thing without my patch and still same test are failing.
Am I missing any steps in the build and patch testing?
Thanks & Regards,
Deepak
> Memory leaks in zoo_multi API
> -----------------------------
>
> Key: ZOOKEEPER-1562
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1562
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.4.3, 3.4.4
> Environment: Zookeeper client and server both are running on CentOS
> 6.3
> Reporter: Deepak Jagtap
> Assignee: Marshall McMullen
> Priority: Trivial
> Labels: patch
> Fix For: 3.4.5
>
> Attachments: ZOOKEEPER-1562.patch
>
>
> Valgrind is reporting memory leak for zoo_multi operations.
> ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are definitely
> lost in loss record 18 of 24
> ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
> It looks like completion entries for individual operations in multiupdate
> transaction are not getting freed. My observation is that memory leak size
> depends on the number of operations in single mutlipupdate transaction
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
