Re: [lizard] A few ideas

[Aditya T. <woo...@ya...>]

--- Soam Vasani <soa...@co...> wrote:

 
> I think i understand the problem you describe... 
> but could you slow down
> a bit and explain the solution you're proposing ?
> 
> (1) If we just want to check whether the interface
> is used correctly, you
> don't need a replay debugger or any sort of
> checkpointing, right ?
> You just trace the program's calls to the interface,
> and walk the
> state machine, signalling an error when the state
> machine shows one.
> 
> (2) If you want to actually take the user to the
> place where the error is
> and allow him to go back/forward, then a regular
> trace+checkpoint thing
> is required in addition to checking the state
> machine; so then this is
> no cheaper than replay debugging.

These are exactly the 2 methods i proposed: if you
know the state machines before you execute you can
track just the state machine states. 

If you dont know the state machines, then all you can
do is checkpoint/trace normally (as you said) and do
the tracking of the state machine state in the debug
session.

> > Given these state machines, you can either
> checkpoint the whole state during
> > execution and later during the debugging session,
> do the appropriate state
> > machine updates and all that jazz.
> 
> this part i didn't understand.
> 
> > This way the user can change the state machines
> during the debugging session.
> 
> nor this.  (and also, why would one want to change
> the state machine during
> the debug session ?)
> 
> > OR
> > Only save enough state (using dynamic slicing) to
> provide information
> > regarding the relevant variables affecting the
> state machines you are
> > tracking.
> 
> ok, but i still don't know what you're saving state
> for in the first place.

these are the 2 points you mentioned above, which i
re-iterated again.

another way of looking at it: 
the states represent some sort of user defined
abstractions of the program state. the state might not
necessarily represent any error states. for e.g. you
can just see if a variable is +ve or -ve, instead of
the actual value. so each state is associated with a
predicate which depends on certain variables. 

coming back to the question of what to save: the
predicates might be too complicate to evaluate at
run-time. so you can just dump the variables which the
various states depend on and evaluate the actual state
at debug time. another reason you would want to save
the variables is that the user might want to see why
the machine is in that state for e.g. if your 2 states
are SORTED and UNSORTED for an array; then having the
array at hand to see which positions are "unsorted"
might be usefull to determine the bug.

anyway, i'm going too far again. but i hope the main
problem is clear: abstract the program state and
provide legal moves from one abstract state to the
next by specifying predicates on the program state and
a finite state machine.

the rest you can play around with and see what makes
sense.

Aditya

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com