Question

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. ;-)

Was it helpful?

Solution

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.

OTHER TIPS

On AIX, you want to use stophwp:

(dbx) help stophwp

stophwp <address> <size>

        Stop execution when the contents of the specified
        memory region change.  This is a accomplished in
        hardware and may not be available on all models.

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top