Comments on: Finding uninitialized memory and corruption If you're on a Windows platform I second this if you can't get DUMA to work. Also, here's the debug heap variant. http://msdn.microsoft.com/en-us/library/e73x0s4b%28v=vs.71%29.aspx If you're suspecting something stomps on memory, there's a good chance it's <em>always</em> stomping on memory (even if you only sporadically get a crash.) You can use a variant of your "division in half" technique without having to disable anything and just put verify calls around the code and break it down from there. <code> _ASSERTE(_CrtCheckMemory()); SuspiciousSystem(); _ASSERTE(_CrtCheckMemory()); </code> If you hit the bottom assert then you go narrower, if you hit the top assert then you go broader. You can start by putting this around your main loop just to verify that you actually <em>can</em> detect corruption with it. If you’re on a Windows platform I second this if you can’t get DUMA to work. Also, here’s the debug heap variant.

Nice trick! You can also have some features of hardware breakpoints (like data breakpoints on read/execution) without manually dealing with the debug registers by using WinDbg instead of the VS debugger. <a href="http://www.codeproject.com/KB/debug/windbg_part1.aspx" rel="nofollow">Reference</a> (look for "hardware bp"). Nice trick! You can also have some features of hardware breakpoints (like data breakpoints on read/execution) without manually dealing with the debug registers by using WinDbg instead of the VS debugger.

Reference (look for “hardware bp”).

]]>
By: Bernat Muñoz/2011/05/30/finding-unitiliazed-memory-and-corruption/#comment-5015 Bernat Muñoz Tue, 31 May 2011 11:21:28 +0000 I actually wanted to talk about the poor version of that technique, which basically involves hooks to all your allocs/frees, an oversized buffer, and setting prior and following areas to known magic values. Then, when freeing memory (or periodically, if you have a list of your allocations), check if those values changed. It's rather simple to do, and should be portable :) Any way, your technique seems a cheap and easy to code DUMA replacement, so I'll implement it and blog about it in the future, thanks! I actually wanted to talk about the poor version of that technique, which basically involves hooks to all your allocs/frees, an oversized buffer, and setting prior and following areas to known magic values. Then, when freeing memory (or periodically, if you have a list of your allocations), check if those values changed. It’s rather simple to do, and should be portable :)

Any way, your technique seems a cheap and easy to code DUMA replacement, so I’ll implement it and blog about it in the future, thanks!

]]>
By: Bernat Muñoz/2011/05/30/finding-unitiliazed-memory-and-corruption/#comment-5013 Bernat Muñoz Tue, 31 May 2011 11:09:33 +0000 I`d like to mention technique I use. The tool is "event replay subsystem" built into game itself. It is a small library which allows to run debug session in 2 steps: 1) you try to catch some corruptions 2) you replay saved events and try to analyze what is happening On second step pretty everything is reproduced, things like access to invalid pointer is a nutshell. However there is a second order of instability, when replay does not reproduce the same result (usually due to wrong replay integration). For this I have sort of log with "compare and replace" option, which triggers a breakpoint as soon as some variance is detected. I write to this log things which indicate different code path, like stack pointer. I`d like to mention technique I use. The tool is “event replay subsystem” built into game itself. It is a small library which allows to run debug session in 2 steps:
1) you try to catch some corruptions
2) you replay saved events and try to analyze what is happening
On second step pretty everything is reproduced, things like access to invalid pointer is a nutshell.
However there is a second order of instability, when replay does not reproduce the same result (usually due to wrong replay integration). For this I have sort of log with “compare and replace” option, which triggers a breakpoint as soon as some variance is detected. I write to this log things which indicate different code path, like stack pointer.

]]>
By: John Carmack/2011/05/30/finding-unitiliazed-memory-and-corruption/#comment-5003 John Carmack Tue, 31 May 2011 01:51:34 +0000 A subset of what it sounds like DUMA is doing: if you're lucky (hah) enough to have a specific variable/address occasionally overwritten as a result of a memory stomp, the x86 debug registers can be a great help. Add an exception-on-write for an address and you'll get a debugger break/minidump (if your users are setup for that) at the point it happens. http://www.codeproject.com/KB/debug/hardwarebreakpoint.aspx is a good reference. A subset of what it sounds like DUMA is doing: if you’re lucky (hah) enough to have a specific variable/address occasionally overwritten as a result of a memory stomp, the x86 debug registers can be a great help. Add an exception-on-write for an address and you’ll get a debugger break/minidump (if your users are setup for that) at the point it happens.