crtdbg: fix MSVC CRTDBG memory leak reporting

[jeffhostetler]

Teach git to report memory leaks both to a file and to the
VS debug output window.

From the SDK command line, build Git as follows:

make MSVC=1 DEBUG=1 CRTDBG=1

When built this way, leaks will always be reported to the
Visual Studio debug output window.

Enable GIT_TRACE_CRTDBG and the leaks will also be reported
to the trace target. This works from both the command line
and from Visual Studio.

Signed-off-by: Jeff Hostetler [email protected]

[jeffhostetler]

@dscho This is self-contained and Windows-specific. Let me know if you'd rather I send this upstream first. I wasn't sure about how much of the low level windows stuff is upstream.

[jeffhostetler]

The last 2 commits are probably duplicate too much code. These changes let us get the file/line of the
actual call to x*alloc() rather than the file/line of the code within wrapper.c that calls the actual CRT
alloc routine. Without these all leaks are attributed to the body of xcalloc/xmalloc/xrealloc themselves
and is not that helpful. To be useful, we need to capture the data for the caller of xcalloc and friends.

I only converted the most common routines. I didn't really like how I had to do this (lots of duplicated
code), but we can talk about alternatives if we want to pursue this patch.

[jeffhostetler]

Here is a version that tries to eliminate the duplicated code blocks and make minimal changes in upstream code sections. It might be possible to make this even skinnier, but I think this is pretty close.

[jeffhostetler]

BTW, it's OK if you just want to say "no" on this PR. I understand. Memory leaks aren't taken that serious, since exit() works just fine for most uses.

[dscho]

BTW, it's OK if you just want to say "no" on this PR

Thanks. I think I'd like the changes, though... I just need to understand the intricacies, and I need to come up with a way that would be acceptable by core Git. The less platform-specific stuff we can introduce outside git-compat-util.h/compat/*, the better.

[dscho]

@jeffhostetler I'll close this for now, okay?

If we need to resurrect it, we will probably have to redo it, what with pcre2_malloc(), xdl_malloc() and similar instances where we wrap malloc().

[jeffhostetler]

that's fine. and yes, with all the changes to the build system since then, we'd need to retool it anyway.