Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definite memory leak in libhrd_cpp #7

Open
kristianmitk opened this issue Feb 18, 2020 · 0 comments · May be fixed by #8
Open

Definite memory leak in libhrd_cpp #7

kristianmitk opened this issue Feb 18, 2020 · 0 comments · May be fixed by #8

Comments

@kristianmitk
Copy link

I ran a vagrant analysis that revealed the following definite memory leaks in libhrd_cpp caused by the memcached connectors:

==37850== 1,168 bytes in 1 blocks are definitely lost in loss record 65 of 82
==37850==    at 0x4C2FA3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x4C31D84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x549639F: memcached_server_list_append_with_weight (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x10E682: hrd_create_memc() (hrd_util.cpp:332)
==37850==    by 0x10E7DC: hrd_publish(char const*, void*, unsigned long) (hrd_util.cpp:351)
==37850==    by 0x10C53E: hrd_publish_conn_qp(hrd_ctrl_blk_t*, unsigned long, char const*) (hrd_conn.cpp:396)
==37850==    by 0x10F69E: main (main.cpp:170)
==37850==
...
==37850== 2,048 bytes in 2 blocks are definitely lost in loss record 68 of 82
==37850==    at 0x4C2FA3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x4C31D84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x549A09C: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x54949FF: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x5494E26: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548DD99: memcached_fetch_result (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548DF91: memcached_fetch (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548F68C: memcached_get_by_key (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548F889: memcached_get (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x10E92F: hrd_get_published(char const*, void**) (hrd_util.cpp:383)
==37850==    by 0x10EBB6: hrd_wait_till_ready(char const*) (hrd_util.cpp:434)
==37850==    by 0x10FA17: main (main.cpp:231)
==37850==
...
==37850== 2,048 bytes in 2 blocks are definitely lost in loss record 69 of 82
==37850==    at 0x4C2FA3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x4C31D84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==37850==    by 0x549A09C: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x54949FF: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x5494E26: ??? (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548DD99: memcached_fetch_result (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548DF91: memcached_fetch (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548F68C: memcached_get_by_key (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x548F889: memcached_get (in /usr/lib/x86_64-linux-gnu/libmemcached.so.11.0.0)
==37850==    by 0x10E92F: hrd_get_published(char const*, void**) (hrd_util.cpp:383)
==37850==    by 0x10EBB6: hrd_wait_till_ready(char const*) (hrd_util.cpp:434)
==37850==    by 0x10FA4E: main (main.cpp:234)
==37850==
...
==37850== LEAK SUMMARY:
==37850==    definitely lost: 5,264 bytes in 5 blocks
...
@kristianmitk kristianmitk linked a pull request Feb 18, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant