views:

395

answers:

2

A co-worker has a C program that fails in a predictable manner because of some corrupted memory. He'd like to use dbx to monitor the memory location once it's allocated in order to pinpoint the code that causes the corruption.

Is this possible? If so what is the syntax to produce a breakpoint at the moment of corruption?

If not, what would be a good approach to fixing this sort of issue?

(My usual tactic is to look at the source control to see what I've changed lately, since that is usually the cause. But the code in question sounds as if it only ever worked by luck, so that won't work. Also, I've already eliminated myself as the culprit by never having worked with the code. ;-)

A: 

I'm no Solaris dev, but you can do this with gdb and hardware breakpoints

Paul Betts
+1  A: 

Having looked more deeply, it appears the solution on recent versions of dbx is something like:

stop access w <address>, <size>

Since <address> and <size> can be expressions, you can write commands like:

stop access w &p, sizeof(int)

This assumes p is a pointer and we want to monitor the first word it points to.

I've also run across a fine tutorial on tracking and stomping memory bugs. It uses gdb rather than dbx, but the principles should be the same.

Jon Ericson