A Better C/C++ Data Breakpoint and a Better Java Watchpoint

In C/C++ some of the toughest bugs are memory overwrites or corruption issues. To address these sorts problems, today’s hardware allows debuggers to set a few breakpoints on memory access without any performance penalty. This is a great thing if you know the specific address that is going to change. You can place a data breakpoint on it and quickly unmask the offending culprit. Finding stack overwrites, unanticipated callbacks, or just bad logic is efficiently deduced this way.

But often times you don’t know the memory address since it can change from one run to the next, or it is not known until it’s already too late. In these cases, there really isn’t a place to put a data breakpoint, and you have to resort to more traditional methods such as logging and scanning.

This unknown memory issue has really been improved for us by using Replay internally. Whenever we having a corruption issues in a recording, we always know the correct memory address. We start the debugger, set the data breakpoint to the corrupted addressed from the previous run, and let the replay trigger all the sources that contributed to the problem.

For Java, although we don’t have direct access to memory, watchpoints act in a similar fashion. If an object’s field is going to be corrupted or changed by an unknown source, you would set a watchpoint on that field. This provides a more targeted trigger than a data breakpoint, but there often is another problem. You may want to limit it to a particular object instance, or there may be too many watchpoints to examine and debug.

With Replay, the process is to first acquire the internal id or name of the corrupted object. Next you set a watchpoint on its field, but also make it conditional on the id or name of the object. When the replay is fired off, it should really pinpoint the problem quickly without having to filter through many unwanted breaks on unrelated objects.

To wrap up, data breakpoints and Java watchpoints provide an invaluable technique to track down some corruption issues, if they have predictability. But when you couple the ability to use Replay and set data breakpoints and watchpoints, we have a powerful new tool. The same process will always work from one scenario to the next. We now have a reliable data breakpoint and watchpoint debug technique that will allow us to track down these types of problems.