[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Preventing App Crashes before Bug Fixes
From:       Adriaan de Groot <adridg () cs ! kun ! nl>
Date:       2004-03-24 13:02:32
Message-ID: 200403241402.37607.adridg () cs ! kun ! nl
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Sticking to just -devel.]

On Wednesday 24 March 2004 11:33, Amir Michail wrote:
> On Wed, 24 Mar 2004 07:40 pm, Adriaan de Groot wrote:
> > Right, so now halfway through a function it turns out the function has
> > caused problems in the past and the user wants to bail out of it - what
> > do you need to roll back? Allocations? What about displaying the dialog
> > immediately prior to the crash?
>
> I was hoping to avoid roll back all together by intercepting input events
> and giving the user a chance to cancel those input events that could result
> in a crash or bad behavior.  Since the application would never get those
> input events, there would be no need to roll back.

Ah, ok, a higher level than anything identifiable at the source-code level. 
Based on the input (lots of traces of executions) you get, you can (try to) 
reconstruct a nondeterministic automaton model of the application. 
Transitions that cause a crash can be marked as such, and the user warned. A 
big question then is when should we consider an action as one which creates a 
new state (in the automaton model) and when should we re-use an existing 
state? An inital model is of course one-state with a single loop-self 
transition, this represents all you can know about the application at the 
outset.

There is related research in Tilburg, on reconstructing database models and 
organizational process charts based on database transation logs.


> As presented, the application would transfer  input events and other data
> in real-time to the bug reporting server and would get new bug avoidance
> data as soon as it is available from the server.

OK, so: type a letter in KMail's composer. "letter typed" sent to bugsystem, 
which may update its model in real-time, and which evaluates which transition 
in the model is taken with this action; "risk level" of transition is sent 
back. Risk level is checked, possible user ok required, and then the action 
is sent to the application itself. You can hook into the X event stream like 
an electric guitar effects box to achieve this. Delays will be considerable - 
and don't get me started on "you seem to have moved the mouse. The risk level 
with doing this in this application is 86%. Do you really want to move the 
mouse?"

Back to the topic, that _is_ interesting research.

- -- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot@kde.org>
                     Would you like a freem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAYYbtdqzuAf6io/4RArkJAKCZvH1YIcn4/g/SGiDuOlFJYETOdwCdGDlN
74zf8/RRKDVTLDrVvCatXhA=
=gXdo
-----END PGP SIGNATURE-----
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]