views:

191

answers:

5

Hi everyone

We have a memory overwrite problem. At some point, during the course of our program, a memory location is being overwritten and causing our program to crash. the problem happens only in release mode. when in debug, all is well. that is a classic C/C++ bug, and a very hard one to locate.

I wondered if there's a way to add some 'debugging code' that will watch this memory location and will call a callback once its changed. This is basically what a debugger could do in debug mode (a 'data breakpoint') but we need something similar in release.

thanks very much for any idea,

Lior

+8  A: 

If you can control the location of the variable then you can allocate it on a dedicated page and set the permissions of the page to allow reads only using VirtualProtect (on Windows ... not sure for Linux).

This way you will get an access violation when someone tries to write to it. With an exception translator function you could treat this as a callback.

Even if you can't move the variable directly (eg. it is a class member), maybe you could add sufficient padding around the variable to ensure it is on a dedicated page and use the same approach.

Rob Walker
It would be mprotect() on linux.(I was about to post the same thing - but you beat me to it)
Aaron
This is your best suggestion. Performant data breakpoints require hardware support to watch the memory range - if the hardware doesn't support it the debugger has to single step execution and then manually check that the memory range has not changed.
R Samuel Klatchko
+6  A: 

You can still generate debug symbols for a "release" piece of code. This can still be run through a debugger just like you would in "debug" mode.

I recently did something similiar with one of our release drivers so that we could run it through vtune. For the Microsfot LINK, I added the -DEBUG flag, for Microsoft CC I added -Zi. Everything works fine. MSKB link

You might find this link useful.

Pod
+1  A: 

There are tools for this - like heap agent and boundschecker and many others that will discover overwrites. Basically you need some sentinels at the end of your memory allocations and they need to be checked.

Tim
+3  A: 

assuming you're using windows use windbg to debug your program and check out the ba command-this will break when the memory is accessed.

jolyon
Use this in combination with the debug symbols I mentioned for best results ;)
Pod
A: 

Debugging APIs are platform-specific, but they do exist. Windows and UNIX APIs can be found online.

Max Lybbert