Memory corruption tool for MSVC

[OneEyeMan]

Hi, ALL,
I'm trying to create an application with MSVC 2010 Pro.
Unfortunately the application crashes.

I tried to recreate the problem by creating simple console application or simple MFC-based application, but unsuccessfully. Everything works.

So at this point I'm in need in the valgrind-like tool for MSVC. If Pro version have something like this already, it would be nice - otherwise I would need something free. This link (answer 2) gives couple, but I specifically need a tool to check for memory corruption and I didn't see any that explicitly mention it.

So can someone please give me some hint of what I can use to find a memory corruption?

My application uses wxWidgets and SQLite and it also uses DLLs. What I'm trying to do is allocate memory in a DLL and release it in the main application when it finishes. And when I try to call delete the crash occur.

I check and the addresses of the pointer being allocated and the pointer being deleted are the same, but for some reason, I guess it just starts pointing to something else.

So as I'm out of ideas of how to debug it, I'm looking for a tool to help me find where the memory corruption occur.

Thank you in advance for any pointers.

[2kaud]

What I'm trying to do is allocate memory in a DLL and release it in the main application when it finishes.

That's a bad idea. If the DLL allocates memory then the DLL should free it. See
http://stackoverflow.com/questions/1...to-it-to-a-cli

[OneEyeMan]

Hi,

That's a bad idea. If the DLL allocates memory then the DLL should free it. See
http://stackoverflow.com/questions/1...to-it-to-a-cli

Well, even if I try to load DLL again and delete the pointer, it still crashes. So I do need the tool to find out the cause.

Thank you.

[2kaud]

Hi,


Well, even if I try to load DLL again and delete the pointer, it still crashes. So I do need the tool to find out the cause.

Thank you.

Load the DLL again? The same instance of the DLL should allocate and delete the memory. Are you using LoadLibrary()? If yes, then between the memory allocation and deletion within the same DLL you don't free the loaded DLL which contains these functions.

See the memory debuggers referenced in this article. https://en.wikipedia.org/wiki/Memory_corruption

[Arjay]

Hi,


Well, even if I try to load DLL again and delete the pointer, it still crashes. So I do need the tool to find out the cause.

Thank you.

You need to refresh your memory and relearn how dlls are loaded and mapped into the process address space. Once you remember how this occurs, then you will understand why you can't unload/reload a dll and reuse a pointer.

[zerver]

If you still need a memory corruption tool that works, here is one:
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
There is another one called DrMemory.

Both have a hefty negative performance impact, and the memory usage will also skyrocket.

[OneEyeMan]

2kaud,
I have an MFC application that works to prove that allocating memory in DLL and releasing in main application works OK.
Unfortunately even after archiving it still too big to post here as an attachment.

Trouble is - if I do exactly the same thing with wxWIdgets program just crashes on exit when the pointer should be deleted.

I can even create a simple console application which will do this - "new" in DLL, "delete" - in main app. And it will work.

So, I'm going to try to use wx forum and see what people out there can come up with.
But if you or someone else can give me some File Sharing service to upload my MFC test app for review - it would be great. Just to prove a point that it will work this way.

Thank you.

[Arjay]

Delete the debug/release folders and ncb files before zipping the sln.

[OneEyeMan]

Delete the debug/release folders and ncb files before zipping the sln.

Already did. The size is 1698K and it still big.

Thank you.

[2kaud]

I can even create a simple console application which will do this - "new" in DLL, "delete" - in main app. And it will work.

Probably. If everything is set-up just so and the CRT is happy then yes, this will work. However this situation is very fragile and prone to problems if anything changes that upsets the CRT. For production code if smart pointers can't be used then memory should be either allocated/freed in the .exe or allocated/freed in the same dll and the dll kept loaded between the first call to allocate and the last call to free.

We had a similar problem to this a few years ago which was fixed by only allocating/freeing memory in the same dll.