Valgrind +-泄漏检查->不泄漏摘要

Question

I have a multithreaded program which calls an extern library (log4cplus).
When I log something, the memory consumption raises, but never decreases.

I ran valgrind with the --leak-check=yes option. I get :

HEAP SUMMARY
    ==413==     in use at exit: 2,944,909 bytes in 23,429 blocks
    ==413==   total heap usage: 99,472,873 allocs, 99,449,444 frees, 8,049,350,322 bytes allocated

But I didn't get any leak memory summary.

1. Does that mean that the 2,944,909 bytes are still reachable, and so are released when stopping the process ?
2. How to know if the culprit is my program or the lib ?

---

As suggested below, I added an option to get more details. I've got a very long report. Here is an extract :

==18326== 6,480 bytes in 15 blocks are still reachable in loss record 3,959 of 4,015
==18326==    at 0x482B728: operator new(unsigned int) (vg_replace_malloc.c:328)
==18326==    by 0x15F04F8: __gnu_cxx::new_allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent>::allocate(unsigned int, void const*) (new_allocator.h:104)
==18326==    by 0x15EFB7F: std::allocator_traits<std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::allocate(std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent>&, unsigned int) (alloc_traits.h:416)
==18326==    by 0x15EF320: std::_Deque_base<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::_M_allocate_node() (stl_deque.h:600)
==18326==    by 0x15EE678: std::_Deque_base<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::_M_create_nodes(Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent**, Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent**) (stl_deque.h:725)
==18326==    by 0x15ED5AF: std::_Deque_base<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::_M_initialize_map(unsigned int) (stl_deque.h:699)
==18326==    by 0x15EBFEF: std::_Deque_base<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::_Deque_base() (stl_deque.h:490)
==18326==    by 0x15EB045: std::deque<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, std::allocator<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent> >::deque() (stl_deque.h:884)
==18326==    by 0x15ECF6C: Koin::Common::Containers::StdQueueWrapper<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, true>::clear() (StdQueueWrapper.h:57)
==18326==    by 0x15EB880: Koin::Common::Containers::StdQueueWrapper<Koin::Common::Logging::Log4Cplus::InternalLoggingWrapperEvent, true>::pop_front() (StdQueueWrapper.h:36)
==18326==    by 0x15E9D62: Koin::Common::Logging::Log4Cplus::Log4CplusLoggerProcessor::Execute() (Log4CplusLoggerProcessor.cpp:63)
==18326==    by 0x15F1617: void std::__invoke_impl<void, void (Koin::Common::Logging::Log4Cplus::Log4CplusLoggerProcessor::* const&)(), Koin::Common::Logging::Log4Cplus::Log4CplusLoggerProcessor*>(std::__invoke_memfun_deref, void (Koin::Common::Logging::Log4Cplus::Log4CplusLoggerProcessor::* const&)(), Koin::Common::Logging::Log4Cplus::Log4CplusLoggerProcess  or*&&) (functional:235)

Answer 1

1. Yes

2. Use the valgrind flags --leak-check=full --show-reachable=yes This will dump out the location of all the reachable memory and you need to take it from there to reason about who should be responsible for disposing that memory.

As an example for this program:

#include <stdlib.h>

char *var;

void myfunc(char *c)
{
    var = c;
}
int main(int argc, char *argv[])
{
   myfunc(malloc(4));

    return 0;
}

$ valgrind   --leak-check=full --show-reachable=yes ./a.out 
==21480== Memcheck, a memory error detector
==21480== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==21480== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==21480== Command: ./a.out
==21480== 
==21480== 
==21480== HEAP SUMMARY:
==21480==     in use at exit: 4 bytes in 1 blocks
==21480==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==21480== 
==21480== 4 bytes in 1 blocks are still reachable in loss record 1 of 1
==21480==    at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==21480==    by 0x4004DC: main (t.c:6)
==21480== 
==21480== LEAK SUMMARY:
==21480==    definitely lost: 0 bytes in 0 blocks
==21480==    indirectly lost: 0 bytes in 0 blocks
==21480==      possibly lost: 0 bytes in 0 blocks
==21480==    still reachable: 4 bytes in 1 blocks
==21480==         suppressed: 0 bytes in 0 blocks
==21480== 
==21480== For counts of detected and suppressed errors, rerun with: -v
==21480== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6)

Here valgrind will show you that line 11 in main() has allocated 4 bytes memory, and you need to track down where this allocated memory ends up, through myfunc() and so one, and reason about who should deallocate this memory.

As you're using log4cplus, make sure you de-initialize it, as mention in the examples