Diagnosing memory leaks in Windows with UMDH
As a pre-req: I am fairly new to C++ / C
I work with a server side C++ application that recently had a major memory leak. I was able to diagnose and subsequently fix the memory leak with the help of UMDH. The leak was in one of the primary DLLs that is written in C. After correcting this, I started to review other potential leaks that UMDH had reported. The next biggest reported leak appeared to be coming from the Maria DB connector library -> to interact with a SQL DB, we load the Maria DB connector library using LoadLibraryA. This is what one of the call stacks looked like once we got into the DLL:
libmariadb!_heap_alloc_base+0000005D (f:ddvctoolscrt_bldself_64_amd64crtsrcmalloc.c, 55)
libmariadb!_heap_alloc_dbg_impl+0000028D (f:ddvctoolscrt_bldself_64_amd64crtsrcdbgheap.c, 431)
libmariadb!_nh_malloc_dbg_impl+00000039 (f:ddvctoolscrt_bldself_64_amd64crtsrcdbgheap.c, 239)
libmariadb!_nh_malloc_dbg+00000049 (f:ddvctoolscrt_bldself_64_amd64crtsrcdbgheap.c, 302)
libmariadb!malloc+0000002A (f:ddvctoolscrt_bldself_64_amd64crtsrcdbgmalloc.c, 56)
libmariadb!my_malloc+0000009A (c:mariadb-connector-c-2010libmariadbmy_malloc.c, 36)
libmariadb!alloc_root+00000101 (c:mariadb-connector-c-2010libmariadbmy_alloc.c, 81)
libmariadb!mthd_stmt_read_all_rows+000000C9 (c:mariadb-connector-c-2010libmariadbmy_stmt.c, 181)
libmariadb!mysql_stmt_store_result+000003E6 (c:mariadb-connector-c-2010libmariadbmy_stmt.c, 1357)
We pass a pointer to the DLL function and ultimately one of the destructors back in one of our C++ DLL's call's another DLL function (mysql_stmt_free_result) to free the memory pointed to by the identifier that was passed in to the initial call stack I mentioned above. After doing some debugging I have confirmed that the destructor is properly calling up the DLL function to perform the clean up and it is successful.
We are dynamically linking the Maria DB Connector DLL, so this leads me to believe that the heap this DLL is using is different than the heap the DLL that loaded it is using (please correct me if that's wrong). If this is true, I'm wondering if this could be causing issues when UMDH uses the heap manager's facilities to get information about call stacks / outstanding allocations? From what I've read it appears that all heaps associated to a process should be accounted for here. I hope a more experienced individual could provide some insight on this topic.
Edit (Resolution):
After further review, I no longer believe this is a false positive, it appears that the code was not de-allocating the statement handle, you can use mysql_stmt_close to accomplish this. So my suspicions were incorrect and UMDH has prevailed.
链接地址: http://www.djcxy.com/p/91036.html