[e-lang] Draft "Causeway: A message-oriented distributed debugger"

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Terry Stanley wrote:
>> Tyler Close, Mark Miller, and I are writing a paper on Causeway. Our
>> current draft is at
>> <http://erights.org/elang/tools/causeway/cw-paper09.pdf>.
> 
> In the example of section 2.2:
> 
> # In the worst case, potential causality -- the happened-before relation --
> # must be considered. You must examine q2, q3, q4 and q5, although you know
> # know that you can safely ignore q6.
> 
> The potential causality could be automatically narrowed further than implied
> by the happened-before relation. In the example, suppose that the bug that
> manifests at q5 involves a particular subset S of q's state. We can ask
> whether any state change made in q4 could have influenced (in an
> information/control flow sense, based on the semantics of the language
> in which the buggy program is written) any state in S. If not, then q4 can't
> be relevant to the bug.

Subtle point: If q4 failed to perform a state change that q5 was relying on,
then that would not be detected by the flow analysis. However, because q5
(that is, the event that responds to q2) only occurs after q4 in this
execution trace, not for other executions that could have occurred with the
same program code and initial state, it would be a race condition for q5
to depend on any state change made by q4. The bug in that case (and in
other similar cases) would not be in q4, since the race condition would be
present no matter what q4 does. For q4 to be the *cause* of the bug, it
would have to do something that actively "messes up" the state, which would
be detected by the flow analysis.

The argument above stands even if q5 detects that it happened-after q4,
and only then relies on a state change that q4 should have made but didn't.
This is because q5 can only detect that it happened-after q4 by some
state change that q4 makes, which will be detected by the flow analysis.

-- 
David-Sarah Hopwood ⚥