Debugging a Program With dbx

Reaching Breakpoints

If you do not reach the breakpoint you expected to reach, consider the following possibilities:

In this situation, the breakpoint you put on the while amounts to putting a breakpoint only on the outer if, because dbx cannot deal with source lines that map to two or more different addresses.

C++ members and whatis Command

Sometimes the type of a C++ member is missing in the output of whatis. In the following example, the type of member stackcount is missing:


(dbx) whatis stack
class stack {
...
static stackcount;       /* Never defined or allocated */
...
};

When a static class member is not defined or allocated, dbx cannot determine its type so there is no type to print.

Runtime Checking Eight Megabyte Limit

Only access checking has this limit. Leak checking is not affected by this limit.


Note -

On V9, you can work around the eight megabyte limit by using the setenv command to set the USE_FASTTRAPS environment variable to 1. This workaround makes dbx run more slowly and use more memory.


For access checking, RTC replaces each load and store instruction with a branch instruction that branches to a patch area. This branch instruction has an eight megabyte range. If the debugged program has used up all the address space within eight megabytes of the particular load/store instruction being replaced, there is no place to put the patch area. If RTC can't intercept all loads and stores to memory it cannot provide accurate information and so disables access checking completely.

dbx internally applies some strategies when it runs into this limitation and continues if it can rectify this problem. In some cases dbx cannot proceed; it turns off access checking after printing an error message. For workarounds, see Chapter 9, Using Runtime Checking." For more information on the eight megabyte limit, see "RTC's Eight Megabyte Limit".