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.

{ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax}

More information about the Comp.lang.c mailing list