[e-lang] e-lang Digest, Vol 60, Issue 8

Fri Feb 20 20:28:28 EST 2009

Re causway,

When I'm looking at a debugging framework, my first question is
usually, can I still use my debugger of last resort, printf (ok, first
resort)?

You seem to have a _.log() construct.
Is there any way to find an association between a log entry related to
a message in the source vat, and log entries related to a message in
the target vat?
I.e., if I'm investigating a message that originated in turn t1 in vat
a and was handled in turn t2 in vat b, is there a view that lets me
see log messages in t1 and t2 in sequence?

Also, if I do the following,
    vat A logs L1
    vat A sends message M1 to vat B
    vat B handles message M1
    vat B logs L2
    ...
    vat A logs L3
    vat A sends message M2 to vat B
    vat B handles message M2
    vat B logs L4

If I'm debugging a problem with the handling of M2 but have ruled out
handling of M! as a problem, I have two theories to consider
  (1) something is wrong in vat A that caused it to send a bad M2 so I
need to look at the messages in A between L1 and L2
  (2) something is wrong in vat B that caused it to mishandle M2, so I
need to look at the log messages in B between L3 and L4.

Is there a view that lets me find those intervening sequences of events?

Also, if I have a large system, I may have lose some log entries due
to bad disk sectors, lost disks, or chewed tape.  If logs have holes
due to storage degradation, how does that affect debugging?

2009/2/20  <e-lang-request at mail.eros-os.org>:
> Send e-lang mailing list submissions to
>        e-lang at mail.eros-os.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://www.eros-os.org/mailman/listinfo/e-lang
> or, via email, send a message with subject or body 'help' to
>        e-lang-request at mail.eros-os.org
>
> You can reach the person managing the list at
>        e-lang-owner at mail.eros-os.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of e-lang digest..."
>
>
> Today's Topics:
>
>   1. Draft "Causeway: A message-oriented distributed debugger" --
>      please comment (Terry Stanley)
>   2. Re: Draft "Causeway: A message-oriented   distributed     debugger"
>      -- please comment (Toby Murray)
>   3. Re: Draft "Causeway: A message-oriented distributed       debugger"
>      (David-Sarah Hopwood)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Feb 2009 21:24:20 -0800
> From: Terry Stanley <cocoonfx at gmail.com>
> Subject: [e-lang] Draft "Causeway: A message-oriented distributed
>        debugger"       -- please comment
> To: e-lang at mail.eros-os.org
> Message-ID:
>        <3047277a0902192124q7408ed74s68d9cc7a2d5ca2e2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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>. We would
> love to get your feedback on this paper. Of the conferences we are
> currently considering -- PDPTA, DEBS, OOPSLA (see below) -- the first
> deadlines are early next week, so we would appreciate receiving your
> comments by Monday night (2/23).
>
> The paper is not content complete. The sections on event abstraction,
> related work, and future work have not been written. Suggestions for
> related work would be appreciated.
>
>
> The conferences we are currently considering are:
>
> International Conference on Parallel and Distributed Processing
> Techniques and Applications (PDPTA)
> http://www.world-academy-of-science.org/worldcomp09/ws/conferences/pdpta09
> Submit deadline: 2/25, 7 page limit
>
> ACM International Conference on Distributed Event-Based Systems (DEBS)
> http://debs09.isis.vanderbilt.edu/
> Submit deadline: 3/2, 12 page limit
>
> OOPSLA:
> http://www.oopsla.org/oopsla2009/
> Submit deadline: 3/23, 18 page limit
>
> If you know of any other conferences we should consider whose
> deadlines have not yet passed, please let us know. Thanks!
>
> --
>    --Terry Stanley
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Feb 2009 11:05:10 +0000
> From: Toby Murray <toby.murray at comlab.ox.ac.uk>
> Subject: Re: [e-lang] Draft "Causeway: A message-oriented       distributed
>        debugger" -- please comment
> To: Discussion of E and other capability languages
>        <e-lang at mail.eros-os.org>
> Message-ID: <1235127910.5292.17.camel at clpc130.comlab.ox.ac.uk>
> Content-Type: text/plain
>
> On Thu, 2009-02-19 at 21:24 -0800, 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>.
>
> Awesome. Look forward to reading it.
>
> On related and future work, a few things spring to mind:
>
> 1. ProBE
>
> Formal System's (Europe), Limited's ProBE tool for exploring CSP models.
> See http://www.fsel.com/probe_download.html which includes downloads and
> documentation etc.
>
> Quoting from a synopsis about ProBE:
> "ProBE is another offering from Formal Systems. In contrast to FDR's
> automatic checking of properties, ProBE addresses the equally important
> need of the user to gain understanding of a system by interacting with
> it." ... "The user controls the resolution of non-determinism and the
> choice of actions, watching the process evolve in response. Component
> processes can be selected, and their contribution to the larger system
> examined."
>
> ProBE differs from Causeway in that it's not a debugger, but it does
> feature a similar treeview-based UI that allows one to do a "follow the
> message" view of a system (more precisely a "follow the events" view,
> but events usually model messages). ProBE has been around for quite a
> while. It was publicly released in 1997, see
> http://phase.hpcc.jp/phase/swopp-announce/archives/msg00437.html .
>
>
> 2. The work of Alex Groce
>
> Causeway is focused on helping a programmer understand the "cause" of a
> bug, right? It does so by allowing them to examine the trace of events
> the led to the bug, presenting the information in such a way to allow
> the programmer to more naturally understand what caused the failure.
> This process is "manual" in the sense that the programmer must discern
> for him/herself what the cause is, using the information that causeway
> presents. There has been a bit of work on automating sort of thing,
> namely in the automatic analysis of
> sequences-of-events-leading-to-failures to determine which events
> "caused" the failure in question. A notable example is the PhD thesis of
> Alex Groce, see http://www.cs.cmu.edu/~agroce/ . He defines a formal
> definition of causation and then applies this to
> sequences-of-events-leading-to-failures (in the form of
> counter-examples, generated by some model checker that has found a
> sequence-of-events after which some correctness condition is violated)
> to determine the events that caused the failure.
>
> Adding these sorts of capabilities to causeway would be an ideal thing
> to mention for future work IMO.
>
> Cheers
>
> Toby
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Feb 2009 15:32:29 +0000
> From: David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk>
> Subject: Re: [e-lang] Draft "Causeway: A message-oriented distributed
>        debugger"
> To: Discussion of E and other capability languages
>        <e-lang at mail.eros-os.org>
> Message-ID: <499ECD0D.4080300 at industrial-designers.co.uk>
> Content-Type: text/plain; charset=UTF-8
>
> Toby Murray wrote:
>> 2. The work of Alex Groce
>>
>> Causeway is focused on helping a programmer understand the "cause" of a
>> bug, right? It does so by allowing them to examine the trace of events
>> the led to the bug, presenting the information in such a way to allow
>> the programmer to more naturally understand what caused the failure.
>> This process is "manual" in the sense that the programmer must discern
>> for him/herself what the cause is, using the information that causeway
>> presents. There has been a bit of work on automating sort of thing,
>> namely in the automatic analysis of
>> sequences-of-events-leading-to-failures to determine which events
>> "caused" the failure in question. A notable example is the PhD thesis of
>> Alex Groce, see http://www.cs.cmu.edu/~agroce/ . He defines a formal
>> definition of causation
>
> Yes, the same counterfactual-based definition by David Lewis that is used
> in your work on authority analysis for CSP, I notice.
>
> Since a subject is defined to have authority to perform an action
> iff it can cause that action, there is a formalisation of authority
> corresponding to any given formalisation of causality. So we should be
> able to look for instances of excess authority using the same techniques
> that are needed to explain bugs, I think.
>
> --
> David-Sarah Hopwood ?
>
>
>
> ------------------------------
>
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>
>
> End of e-lang Digest, Vol 60, Issue 8
> *************************************
>