Finding Memory leaks in C with Visual Studio 2013

Question

I am using Visual Studio 2013, and taking a course in C programming and we started talking about memory bugs detaction, in particular memory leaks, and how to detect them using Valgrind on Linux.

I want to know if there is a way to detect such memory leaks using VS 2013. I tried searching online but it just leads to lots of articles and blogs and msdn posts and blogs with lots of words like dump files, and analizing them, etc which weird because:

1) It sounds so complex, convoluted and unintuitive it is actually hard to comprehend it.

2) The main reason this is weird is due to the fact that VS is the most advanced IDE around and Microsoft spends so much money on in, yet from what I have read it seems that there is no simple way to use VS to detect memory leaks - certainly no way that's as simple as Valgrind where I only have to compile the program and run the command
valgrind -leaks-check=yes ProgramName

and it simply prints to me all location it thinks there is a memory leak and describes the error (like not freeing memory after allocating it with malloc hence having "dead" memory after the program finishes, or accessing memory that's out of the array bounds)

So my question is how to use VS 2013 in order to achieve the same results and to find out First in high level if there are memory leaks in the program, and second - to detect in a simple manner where those leaks are- preferably without involving dump files (not that I know how to use them anyway in VS).

Answer 1

The answer I offer cannot be perfect as exhaustively explaining ALL features VS2013 etc. offer to find C/C++ heap hickups could be a book well sold. And not a very thin one for that matter.

First, things I will NOT cover:

• sal.h - Semantic annotations (which are also used by MS tools, if provided).
• Not EVERY _Crt* function available. Only a few to give the idea.
• Additional steps an application designer might to add to their design for a "production quality" code base.

Having said that, here a piece of annotated code containing various bugs. Each bug is annotated with how it was possible to detect it by means of what VS2013 has to offer. Either at run time or at compile time or with static code analysis.

The compile time error sections are placed in comments, btw.

#include "stdafx.h"
#include <crtdbg.h>
#include <malloc.h>
#include <cstdint>
#include <cstdlib>

// This small helper class shows the _Crt functions (some of them)
// and keeps the other code less cluttered. 
// Note: This is NOT what you should do in production code,
// as all those _Crt functions disappear in a release build,
// but this class does not disappear...
class HeapNeutralSection
{
    _CrtMemState m_start;

public:
    HeapNeutralSection()
    {
        _CrtMemCheckpoint(&m_start);
    }

    ~HeapNeutralSection()
    {
        _CrtMemState now;
        _CrtMemState delta;
        _CrtMemCheckpoint(&now);
        if (_CrtMemDifference(&delta, &m_start, &now))
        {
            // This code section is not heap neutral!
            _CrtMemDumpStatistics(&delta);
            _CrtDumpMemoryLeaks();
            _ASSERTE(false);

        }
    }
};


static void DoubleAllocationBug()
{
    {
        HeapNeutralSection hns;

        uint32_t *rogue = (uint32_t*)malloc(sizeof(uint32_t));
        if (NULL != rogue)
        {
            *rogue = 42; // Static Analysis without the NULL check: Dereferencing null pointer.
        }
        rogue = (uint32_t*)malloc(sizeof(uint32_t));
        free(rogue);
        // detected in destructor of HeapNeutralSection.
    }
}

static void UninitializedPointerAccessBug()
{
//  uint32_t *rogue;
//  *rogue = 42; // C4700: uninitialized local variable 'rogue' used.
}

static void LeakBug()
{
    {
        HeapNeutralSection hns;

        uint32_t *rogue = (uint32_t*)malloc(sizeof(uint32_t));
        if (NULL != rogue)
        {
            *rogue = 42; // Static Analysis without the NULL check: Dereferencing null pointer.
        }
    }
}

static void InvalidPointerBug()
{
    // Not sure if the C-compiler also finds this... one more reason to program C with C++ compiler ;)
    // uint32_t *rogue = 234; // C2440: 'initalizing': cannot convert from 'int' to 'uint32_t *'

}

static void WriteOutOfRangeBug()
{
    {
        HeapNeutralSection hns;
        uint32_t * rogue = (uint32_t*)malloc(sizeof(uint32_t));
        if (NULL != rogue)
        {
            rogue[1] = 42; // Static analysis: warning C6200: Index '1' is out of valid index range '0' to '0' for non-stack buffer 'rogue'.
            rogue[2] = 43; // Static analysis: warning C6200: Index '2' is out of valid index range '0' to '0' for non-stack buffer 'rogue'.
            // warning C6386: Buffer overrun while writing to 'rogue':  the writable size is '4' bytes, but '8' bytes might be written.
        }
        free(rogue); // We corrupted heap before. Next malloc/free should trigger a report.
        /*
        HEAP[ListAppend.exe]: Heap block at 0076CF20 modified at 0076CF50 past requested size of 28
        ListAppend.exe has triggered a breakpoint.
        */
    }
}

static void AccessAlreadyFreedMemoryBug()
{
    {
        HeapNeutralSection hns;
        uint32_t * rogue = (uint32_t*)malloc(sizeof(uint32_t));
        free(rogue);

        *rogue = 42; // Static analysis: warning C6001: Using uninitialized memory 'rogue'.
    }
}

int _tmain(int argc, _TCHAR* argv[])
{
    // checks heap integrity each time a heap allocation is caused. Slow but useful.
    _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF); 

    AccessAlreadyFreedMemoryBug();
    WriteOutOfRangeBug();
    UninitializedPointerAccessBug();
    DoubleAllocationBug();

    // _CrtDumpMemoryLeaks();
    return 0;
}

Last not least, on Windows CE and in the DDKs (maybe also in the platform SDKs), there used to be the 2 static code checkers "prefast" and "prefix". But maybe they are now outdated.
Additionally, there are MS research projects, going a step beyond sal.h, such as: VCC, which help finding concurrency bugs etc.