1

i have a code which i must fix it. It has a leak, I don't know where is the problem, but i think something is bad done. is there anybody who has the same problem and can help me please?

==3923== 32 bytes in 1 blocks are still reachable in loss record 1 of 2
==3923==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3923==    by 0x652168F: _dlerror_run (dlerror.c:141)
==3923==    by 0x65210C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3923==    by 0x693F475: ??? (in /lib/x86_64-linux-gnu/liblzma.so.5.0.0)
==3923==    by 0x6943DC7: lzma_auto_decoder (in /lib/x86_64-linux-gnu/liblzma.so.5.0.0)
==3923==    by 0x5DB14DC: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5DB1E4F: __libxml2_xzread (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5CFFB08: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5D01674: xmlParserInputBufferGrow (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5CD3E34: xmlParserInputGrow (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5CD921A: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5CEB03C: xmlParseDocument (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923== 
==3923== 44 bytes in 1 blocks are still reachable in loss record 2 of 2
==3923==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3923==    by 0x400FDC0: _dl_signal_error (dl-error.c:90)
==3923==    by 0x40146CF: _dl_open (dl-open.c:715)
==3923==    by 0x652102A: dlopen_doit (dlopen.c:66)
==3923==    by 0x400FFF3: _dl_catch_error (dl-error.c:187)
==3923==    by 0x652162C: _dlerror_run (dlerror.c:163)
==3923==    by 0x65210C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3923==    by 0x693F475: ??? (in /lib/x86_64-linux-gnu/liblzma.so.5.0.0)
==3923==    by 0x6943DC7: lzma_auto_decoder (in /lib/x86_64-linux-gnu/liblzma.so.5.0.0)
==3923==    by 0x5DB14DC: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5DB1E4F: __libxml2_xzread (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923==    by 0x5CFFB08: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1)
==3923== 
==3923== LEAK SUMMARY:
==3923==    definitely lost: 0 bytes in 0 blocks
==3923==    indirectly lost: 0 bytes in 0 blocks
==3923==      possibly lost: 0 bytes in 0 blocks
==3923==    still reachable: 76 bytes in 2 blocks
==3923==         suppressed: 0 bytes in 0 blocks
elhadi dp ıpɐɥןǝ
  • 4,763
  • 2
  • 30
  • 34
  • This is not an actual Memory leak but variables wich are still reachable when the program terminates. Did you declare it as a global variable? – Thomas Sparber Jun 10 '15 at 11:10
  • i was reported as a missed free due to an alloc by valgrind. I Think it is a global variable allocation. I'll see if this memory doesn't grow during long time run. Thank you for your reactivity – elhadi dp ıpɐɥןǝ Jun 10 '15 at 11:53
  • I got same problem on _Xubuntu 16.04 64 bits_ (using the latest _libxml2_ release for that distribution), however I fixed it after reading [this answer](http://stackoverflow.com/a/30403709/3268398) talking about the _GCC_'s `-fsanitize=leak` option. – silvioprog Dec 19 '16 at 02:55

1 Answers1

3

http://valgrind.org/docs/manual/faq.html

"still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.

As said, your code should be alright. :)

user3288244
  • 121
  • 5
  • [http://valgrind.org/docs/manual/faq.html#faq.deflost](http://valgrind.org/docs/manual/faq.html#faq.deflost) – user3288244 Jun 10 '15 at 11:40
  • Yes of course i see what means "still reachable", but as this program was not developped by me, i have posed the question. As i have said i will see if this leak doesn't grow during long time program run – elhadi dp ıpɐɥןǝ Jun 10 '15 at 11:51