locked
Tracking a Memory leak in managed&unmanaged code RRS feed

  • Question

  • Hi,

    I'm expiriencing a massive memory leak in a managed and unmanaged app (I hope it's the right forum for this kind of issue).

    I used DebugDiag to take & analyze a dump of the app (a relevant part of the report added below).

    In the report, you can see that the leak mainly comes from 1,326,792 allocations of 136 bytes.

    Since the call stacks doesn't show any function from my code  (mainy ntdll functions), I wonder how should I continue with my investigation.

    Any ideas or suggestions?

    Thanks.

     

    Call stack sample 1

    Address   0x77ffba60
    Allocation Time   00:05:00 since tracking started
    Allocation Size   136 Bytes


    Function   Source   Destination
    msvcr90!malloc+79   f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163   
    msvcr90!operator new+1f   f:\dd\vctools\crt_bld\self_x86\crt\src\new.cpp @ 59   msvcr90!malloc
    ntdll!RtlAllocateHeap+17c      
    ntdll!LdrpCallInitRoutine+14      
    ntdll!NtTestAlert+c      
    ntdll!_LdrpInitialize+2c1      
    ntdll!ZwContinue+c      
    kernel32!BaseThreadInitThunk+e      
    ntdll!__RtlUserThreadStart+23      
    ntdll!_RtlUserThreadStart+1b      ntdll!__RtlUserThreadStart


    Call stack sample 2

    Address   0x77ffbaf0
    Allocation Time   00:05:00 since tracking started
    Allocation Size   136 Bytes


    Function   Source   Destination
    msvcr90!malloc+79   f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163   
    msvcr90!operator new+1f   f:\dd\vctools\crt_bld\self_x86\crt\src\new.cpp @ 59   msvcr90!malloc
    0x72BC84EF      
    0x72BA9CEA      
    0x72C623ED      
    0x72CB5439      
    ntdll!RtlAllocateHeap+17c      
    ntdll!LdrpCallInitRoutine+14      
    ntdll!NtTestAlert+c      
    ntdll!_LdrpInitialize+2c1      
    ntdll!ZwContinue+c      
    kernel32!BaseThreadInitThunk+e      
    ntdll!__RtlUserThreadStart+23      
    ntdll!_RtlUserThreadStart+1b      ntdll!__RtlUserThreadStart


    Wednesday, December 22, 2010 8:06 AM

Answers

All replies

  • Hi,

    Assuming that the unmanaged code is something that you can modify slightly - you could consider overloading operator new and delete in debug mode and add a pointer to __FUNCTION__ to the allocated memory block and return the address just after this information as the allocated memory - wrapping new and delete in preprocessor macros to hide the difference between debug and release builds.

    Something like -

    TYPE* pElement = NEW(TYPE);

    TYPE* pElement = NEW1(TYPE,ARG1);

    TYPE* pElement = NEW2(TYPE,ARG1,ARG2);

    and so on ... crude - but it might help to give you some idea about the offending allocation ...

    Regards

    Espen Harlinn

     


    Espen Harlinn
    Wednesday, December 22, 2010 5:13 PM
  • Hi Espen,

    Thanks for the reply.

    I think that overloading "new" will not have any affect on the call stacks. The "new" operator is not called directly from my code, it is called from "ntdll!RtlAllocateHeap", therefore I'll have to change the NTDLL new operator...

    Thursday, December 23, 2010 6:40 AM
  •  

    Hi demostans,

     

    Could you please following article Detecting .NET Memory Leaks to check whether it is a Managed Memory Leak or Unmanaged Memory Leak?

     

    If it is a Managed Memory Leak, following articles can help us to debug into the memory issue:

     

    .NET Debugging Demos Lab 6: Memory Leak - Review

    Memory Leak Detection in .NET

     

    use CLR Profiler

    .NET Best Practice No: 1:- Detecting High Memory consuming functions in .NET code

     

    If it is an Unmanaged Memory Leak, you may try Visual C++ General or General Windows Development Issues forum for better support.

     

    Please feel free to let us know if you have  any concern.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by eryang Monday, December 27, 2010 12:53 PM
    Thursday, December 23, 2010 9:54 AM