memory issues on a native c++ app on windows

Question

I'm investigating a bad_alloc crashes for a multithreaded native cpp app, from WinDbg it's clearly happening on allocating large object on heap (mostly basic_string ctor or some array allocation with new operator). From the !address -summary and memory analysis from DebugDiag it's seems like app memory usage is very high but heap size is still very small (around 70 MB).

LFH Key                   : 0x233116ff
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
05f60000 00000002   68964  56804  68964   8411 37570    13    2  29701      
    External fragmentation  14 % (37570 free blocks)
072a0000 00001002      60      4     60      2     1     1    0      0      
096f0000 00001002      60      4     60      2     1     1    0      0      
1f430000 00001002      60      4     60      2     1     1    0      0      
-----------------------------------------------------------------------------

I want to dig deep into the memory from the usage table and find out the cause of higher memory allocation, any suggestion on how to proceed further?

One of the most common causes is mixing signed and unsigned `int`s when calculating the size of a new buffer to allocate (either directly or passing as initial size to any of the the std::collections) eg trying to create a new allocation of size `str.size() - 1` when the string is empty. Run the code under the debugger and MSVS will break in when the exception is thrown, open the stack frame window and move up the stack to find the application code. — Richard Critten, Apr 13 '22 at 08:40
It's intermittent and never seen on debugger with profiler on, with profile mostly private bytes are under 200MB. I'm interested in knowing the further breakdown of Reserved and Committed memory. — Divyank S, Apr 13 '22 at 08:57
You'll have to figure out who is allocating those `MEM_PRIVATE` pages. The system doesn't track this historical information. You'll have to do some sleuthing. Maybe dump those private pages to see what's in them, see if that gives a clue. Or search memory for addresses that correspond to private pages, see if anybody has a pointer to them. Or use the profiling information to see who typically allocates `MEM_PRIVATE` pages and come up with theories as to how they may have gone haywire. — Raymond Chen, Apr 13 '22 at 13:34

memory issues on a native c++ app on windows

0 Answers0