woods@hao.UUCP (Greg Woods) (02/07/84)
The following is a list of bugs in DBX(1), the source-level debugger provided with 4.2BSD, that I have observed so far. It is probably not a complete list. It is not intended as a criticism of the author of DBX nor the folks at Berkeley. I am posting it for the information of the folks on the net who might want to know what works and what doesn't, and to draw attention to them from the people at DEC who are working on fixing bugs in DBX. These bugs were found while testing a small, useless C program whose code I will supply if anyone cares to see it. I have not tested any of the machine-level commands yet. I would like to hear if anyone has either also observed these bugs, have gotten any of the commands that I found bugs in to work properly, or have source-code fixes for the bugs listed here. I hope to have a bug list for DBX and F77 coming up soon. Preliminary testing has shown that the bug list will be similar, but not identical. COMMAND BUGS ------- ---- run This seems to work fine. It also remembers the previous I/O redirections you used the last time you used it, which is both good and bad. To restore the default, you either have to quit and reenter the debugger, or explicitly redirect to /dev/tty. There should be an easier way to restore the default stdin and stdout. trace in routine if cond This will crash the debugger if the condition trace at line if cond involves any floating-point variables that do not happen to have exact integer values. The error message I see is "dbx internal error: stack underflow". They work fine if the condition involves only ints or floats whose values are exact ints. trace routine This works fine once you figure out that subroutine "sub" in "sub.c" is trace-activated by "trace sub.sub" that "trace sub" makes wierd things happen. trace expression at line Same bug as trace if, i e. you get a stack underflow if the result of evaluating the expression is not an exact int. trace variable Works fine, except that if a routine has any sub- blocks in it, the debugger somehow loses information about variables local to the subroutine but outside the block. stop if condition This command is not accepted by the debugger. It seems to want more information. This may be a bug in the documentation rather than the debugger itself. stop at line Works as advertised. (Standard breakpoint) stop in routine if cond Works fine, except that if it hits the stop condition and stops, and then you delete the stop request, the debugger crashes when the routine returns, printing "missing trid %d". stop variable if cond The old floating point bug again. Crashes on a stack underflow error if the condition involves floating-point variables with non-int values. status Works as advertised. delete Works, except that if you give it an invalid command number to delete, it does not print an error message. Also, there should be a way to delete all stops and traces. cont,step,next All seem to work as advertised. print Works fine, and even addresses multiple-dimension arrays correctly. There should be a way to print a large part of an array without having to resort to machine addresses, e.g. I would like to be able to say "print a[0],a[10]" and get 11 values back. set Does not work for floating variables. It seems to always set the variable to zero regardless of the value you specify. Well, that's it for now. Look for a future posting of DBX bugs when working with f77(1) programs. GREG -- {ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax} !hao!woods