Re: Intervention needed?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 19-04-04 10:22 , Paul Rubin wrote:
> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>> The major use for debuggers that I see is in integration testing,
>> where test procedures expect particular values in particular variables
>> (or even exact memory locations) in particular circumstances.
>
> You should really automate tests like that.

As gdb can be scripted, the tests that Maciej describes can probably be 
automated, albeit with considerable effort, especially if the scripts 
should be robust to evolution of the SW under test (changing the line 
numbers of the required breakpoints, etc.)

In my domain (on-board satellite SW) the current practice is to fuse 
unit tests with integration tests, with a relatively smooth progression 
from operation-level tests, through module-level tests, to 
subsystem-level tests, with mostly the same techniques and tools at all 
levels: provide inputs, check outputs and calls (with stubs), measure 
coverage. Debuggers are not used.

It is true that current unit-testing tools do not easily let one see and 
check internal states and values, in the way Maciej describes that gdb 
is used. However, I don't think that gdb or other current debuggers are 
ideal tools for automated checking of internal states. I have seen 
increasing activity (conferences and such) on "run-time verification", 
and I would expect better tools to emerge from those activities.

> I find debuggers very useful for understanding how an unfamiliar piece
> of poorly documented code works.  What are the conditions when this
> function XYZ is called, and how does the program get there?  Load the
> program into debugger, set breakpoint at XYZ, and run.

You see only one _instance_ of an execution. I usually prefer to have a 
static analysis give me call-graph which represents _all_ possible 
executions and gives me a general understanding of the program. But I 
agree that instances can also be useful to check that one's general 
understanding is correct.

Both points (Maciej's and Paul's) support my opinion that "debugger" is 
the wrong word for these tools. Their main use is to _view_ or _inspect_ 
the execution states of a program, not to "remove bugs".

> What happens in case of this other input?  Set breakpoint earlier,
> run with other input and single step to understand flow of the
> program, etc.

That is exactly the form of trial-and-error "debugging" that I abhor, 
because it usually provides a mass of instances from which I find it 
hard to extract any general understanding. Moreover, I find it less 
troublesome to modify the logging/tracing set-up before a re-run. The 
recompilation time is insignificant compared to the thinking time.

> There will always be logic errors in programs too.  Sure you can debug
> them with print statements and recompiles, but debuggers and breakpoints
> basically give you a way to insert the print statements interactively
> and dynamically while the program is running.

Except for real-time, concurrent programs... and with quite some 
problems to "print" complex data structures in readable form.

I do think that we should have ways, and better ways, to inspect and 
check program executions at run time.

One could say that most of the effort, so far, in programming tool 
development has been on means to let programmers define what the program 
_should_ do, with increasingly expressive and powerful programming 
languages and compilers or other means to facilitate the execution of 
the programs so defined.

But work on tools that let us see and understand what the program 
_actually_ does has lagged behind. There has been work on algorithm 
visualization, including work to visualize task switches and inter-task 
communications (scheduling traces), and much work on visualization of 
program outputs, but not much work on presenting program executions in 
understandable yet precise ways.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .