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?
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
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.
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.
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
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