Debuging state.

After reading a previous thread on debugging I got to thinking about an experience of mine involving debugging a hardware device called a digital filter. This was a big deal involving many people.
We knew for sure that this thing wasn’t going to work from the start and had a step by step plan to debug it at the beginning of the project. Even though this was a hardware project the similarities to what is going on now are too obvious to point out. Digital filters are easily modeled using state and are easily implemented using ordinary OOP software.

Now the key idea is that state systems are really feedback systems. This is very obvious from a hardware point of view because that is the way they are built. I can’t draw a block diagram here so I will try to describe it: Digital filters consist of many patterns of the following type. An input is fed into a subtractor(S) then into a register(R), The output of the register is fed to a multiplier(M) and then fed back to the subtractor(S). The loop R,M,S is the feedback loop. The output is usually the contents of R.

Now from this perspective it was obvious to all of us that in order to debug this thing we had to open up the feedback loops at S and simply go around the circuit and compare the actual values with what should be there for a given input based of a simulation. This is a full proof method and produced a working system after many weeks of tedious work and rewiring.

Here is the problem as I see it. State systems and the state abstraction always involve feedback and the feedback loops may not be obvious. The only full proof and deliberate way to debug such as system is to open up the loops and trace results compared to an open loop simulation. Open loop tests were once common and were often built in.

I am not sure what this means but here is one debugging idea. Suppose we design a system or language to carry a list of its states. And suppose also that we can temporally make those states a constant type (ie not updateable). Now theoretically at least we are in a position to trace through various values based on that state. Another idea might be to log or break whenever a state is updated. I wonder what other readers think about this. This is all fairly obvious but I haven’t seen it myself.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Omniscient debugging

Omniscient debugging does something very similar to what you describe, and has a workable Java implementation. Assorted debuggers have been available for some time to allow you to run say, lisp expressions forwards and backwards.

I don't know too much about the particulars of your application domain. However, I find it most helpful to get a little more clever with the testing/debugging suite. If you could just come up with a theorem that describes a property of your system that's relatively simple to correctly implement a check, oftentimes you can even get the tool to basically tell you where the mistake is.

Omniscient debugging sounds i

Omniscient debugging sounds interesting. I will check it out. My owm theory goes like this.

In debugging there are always two systems. The system as it should be. And the system as it is. Because the story above is about hardware, there is a clear separation between the two systems. On the one hand we have a paper theory, and open and closed loop simulations. On the other hand we have the hardware as it is. Theorem: A system works when there is a one to one correspondence between the two systems. I am being deliberately vague about this because I know that it opens a can of worms when one considers theories of testing and testability. (note: I am no expert!)

Now I will demonstrate how little I really know about this. Theorem 2: If the two systems and theories match, one will parse the other. A failure to parse marks the point of disagreement. For me this is really “hands on” and intuitive, and I am not inclined to work this out exactly.

From a practical point of view it seems to come down to this. You can’t methodically and deliberately test the system as it is unless you know the system as it should be using the same partitions and abstractions. (ie you can’t compare a differential equation for a digital filter and the filter itself)