24

Durring my work I regulary face rather common programming error - using some object which has already been freed. This invokes UB in C++. On linux, this kind of problems are usually resolved by using Valgrind tool Memcheck. From Memcheck manual:

Memcheck tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and also where the block was freed.

Memcheck provides me call stack, where the object was deallocated and I can go on and debug the problem. Is there similar tool for windows with the same functionality, preferably free?

Community
  • 1
  • 1
ks1322
  • 33,961
  • 14
  • 109
  • 164

5 Answers5

17

As Lailin Chen pointed out in his answer to this question try one of these:

Dr. Memory: https://github.com/dynamorio/drmemory

UMDH: http://support.microsoft.com/kb/268343

AppVerifier: http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx

xuhdev
  • 8,018
  • 2
  • 41
  • 69
stanwise
  • 2,392
  • 1
  • 15
  • 21
  • I have tried AppVerifier, it does not tell where the object was deallocated. – ks1322 Mar 28 '12 at 16:45
  • 1
    Application Verifier should catch this with full memory protection. When you free the object, it protects the deallocated pages, resulting in any future operations on it throwing an exception. – Collin Dauphinee Mar 28 '12 at 16:58
  • AppVerifier is crap, when running a program with it triggers a breakpoint in intel TBB code... crappy program, but idk maybe it is fine if you disable that check – NoSenseEtAl Jul 02 '13 at 09:17
6

The method that worked for me was to write custom memory manager that provides global operators "new" and "delete", and lock every freed/usued memory block with VirtualProtect. This way any attempt to use freed memory will immediately trigger access violation which you can catch and debug. However, to be able to do this, you must "grab" all available memory (or 3/4 of it) using something like VirtualAlloc and every memory block you return (from this initially allocated block) must be PAGE_SIZE aligned (see GetSystemInfo documentation), otherwise you won't be able to lock it reliably. Which means that even trivial application might require large amount of memory to use this method.

As for "valgrind alternative for windows" - I havent heard of it. Somebody somewhere posted that it might be possible to compile/use valgrind with cygwin, but I don't know if this is true or not.

Community
  • 1
  • 1
SigTerm
  • 26,089
  • 6
  • 66
  • 115
5

Here's a valiant Valgring attempt, and I wish them the best:

http://sourceforge.net/p/valgrind4win/wiki/Home/

I am afraid, though, that in order to implement a proper "Valgrind for Windows", access to Windows source code is required.

IOW: When pigs fly.

5

According to Dr. Memory documentation, there is -delay_frees_stack option with exactly the same Valgrind functionality. From Option Reference:

-delay_frees_stack 
default: false 
Record callstacks on free to use when reporting use-after-free or other errors that overlap with freed objects. There is a slight performance hit incurred by this feature for malloc-intensive applications.

Also here is an example of error reported by Dr. Memory:

Here is another example, using the -delay_frees_stack option to obtain the callstack of the freed memory:

Error #8: UNADDRESSABLE ACCESS: reading 0x001338a8-0x001338ac 4 byte(s)
# 0 unaddr_test1                    [e:\derek\drmemory\git\src\tests\suppress.c:110]
# 1 test                            [e:\derek\drmemory\git\src\tests\suppress.c:269]
# 2 main                            [e:\derek\drmemory\git\src\tests\suppress.c:297]
Note: @0:00:02.141 in thread 3024
Note: next higher malloc: 0x001338e8-0x00133938
Note: prev lower malloc:  0x001337e8-0x00133820
Note: 0x001338a8-0x001338ac overlaps memory 0x001338a8-0x001338c4 that was freed here:
Note: # 0 test                            [e:\derek\drmemory\git\src\tests\suppress.c:269]
Note: # 1 main                            [e:\derek\drmemory\git\src\tests\suppress.c:297]
Note: instruction: mov    (%eax) -> %eax
ks1322
  • 33,961
  • 14
  • 109
  • 164
3

What worked best for me was using Visual leak Detector, all I needed to do was to include:

#include <vld.h>

at the beginning of the executables I wanted to test. Then running a debug executable from within windows, would provide detailed information about all leaked memory. From the output you can directly get to the line where the memory was allocated, so you can take care

Frank
  • 1,122
  • 9
  • 12