4.2BSD: DBX bug list for C
Greg Woods
woods at hao.UUCP
Tue Feb 7 10:27:23 AEST 1984
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
More information about the Comp.lang.c
mailing list