Memory clobber situations
For applications that allocate memory for variable sized dynamicdata structures, memory clobber problems are bugs that occur. These can be extremelydifficult to diagnose since the source of the bug is most likely completely unrelatedto the instance of the program buggy behavior.
First the bug must be repeatable. If this clobber is due to anuninitialized variable bug, then the following method will probably not work. Withthat said...
You first need to determine what data has been clobbered. Thisis usually not overly difficult since the program is probably acting badly due tothe clobbered data item(s).
Now you need to write down the memory address of the clobbereddata. The variable name is not likely to be useful since the clobbered data is likelyto be in an allocated data structure. The data window gives you the address of alldata items.
You want to set a When memory is written breakpoint onthis address. The trick here is that you will need to enter the breakpoint memorylocation as a raw address, which has no type. You do not care about the type, youjust care about the size of the type. Choose one the of the basic internal data typesthe debugger supports and coerce the raw address expression to this data type. Forexample: [12345678h]:UDWORD. This has a real address of 12345678h and the data typeis 4 bytes in size which works for integers and pointers.
Now that you have your memory breakpoint set, Restart your program.
You are probably going to have an annoying problem here. Thememory address you are referring to probably does not yet exist because it existsin allocated memory. Allocated memory addresses are not valid until the memory isallocated from the operating system, and when your program starts no memory has yetbeen allocated. You are probably going to need a breakpoint set somewhere in yourprogram to get you beyond the point where the memory you referencing in the memorybreakpoint has been allocated by the operating system, but everything is the programstill operating correctly. It can be tricky to find a good breakpoint location forthis since this chunk of memory may be legitimately deallocated and allocated multipletimes before the erroneous situation. Once you have this breakpoint location youwill want to disable the memory breakpoint, execute your program to the stoppingbreakpoint just discussed, and then enable the memory breakpoint. The debugger shouldnot complain about a bad expression if the memory address is valid.
Note: Do not insert any memory allocation calls to makegetting a valid address easier, because it will likely change the address of yourclobbered memory location and it probably took you some time to find this location.
Now run your program. Every time the memory breakpoint locationis written to by any piece of code anywhere the debugger will stop your programsexecution at that instruction. It could, and very well likely be, that most of thesewrites are correct code. Check each one and if it is okay then continue running theprogram by single stepping off the memory write and then letting the program run.
If the memory block with the clobbered data is allocated anddeallocated multiple times between your stopping breakpoint and the bad memory writeyou are probably going to stop inside the memory manager of runtime system. Thisis a pain and you are just going to have to analyze if everything is still runningokay. The point here is try to get the best stopping breakpoint you can before usingthe memory breakpoint to minimize the false stops.