Preventing App Crashes before Bug Fixes

Amir Michail amichail at cse.unsw.EDU.AU
Wed Mar 24 01:16:46 GMT 2004


Hi,

We are thinking of working on a method for preventing KDE applications
from crashing before the source code is fixed.

We would like to know if the KDE community would be interested in
this.

As an example of the approach, suppose you are using a word processor.

If it crashes or something bad happens, you would send a bug report to
a central bug reporting server. This bug report contains some
input/state history before the crash.

The central server would use machine learning techniques to generalize
the sorts of inputs/states that lead to crashes / bad behavior.

Users would then be warned whenever they are about to enter a sequence
of commands that is likely going to lead to bad behavior/crash. In
fact, the warning could include the bug report descriptions.

In this way, you would avoid bugs even before they are fixed.

I think such an approach makes sense in several contexts:

* when the effort required to fix a bug is greater than the effort
  required to avoid it

* when the code is highly unstable (e.g., alpha/beta code) but it is
  still desirable to have the application be as stable as possible
  so that you would get a lot of feedback from users

When we posted this suggestion to the KDE community on orkut, several
concerns were raised by Aaron Seigo:

* application slowdown
* privacy
* non-deterministic bugs
* resources required for bug reporting server

>From a research point of view, we are less concerned about application
slow down, since these are mostly present day concerns and may not be
such a big deal in a few years with faster computers.  Moreover, even
with present day computers, we suspect that most KDE applications are
already fast enough and the slow down would not be so noticable -- and
in any case is probably more tolerable than crashes/bad behavior.

As for privacy, we don't need to for example send every character
typed by the user to the server in real-time.  We could simply send a
message indicating that a character was typed -- without specifying
which one.  Of course, we would need to distinguish typing into a text
area say vs issuing a command since the latter obviously requires the
particular character typed to be sent to the server.

Non-deterministic bugs are an issue.  However, by gathering data from
many bug reports, I suspect that machine learning methods can identify
causes of some of these non-deterministic bugs and issue warnings
appropriately.

As for resources for the bug server, this is really an issue that
would come up only if/when the system is successful and has many
users.  If that happens, we could think about having many servers to
handle the load.

Amir

P.S.

Some extensions of this idea using similar infrastructure:

* perhaps we can go further and automatically (or semi-automatically)
  find and carry out workarounds for bugs

* allow users to collaboratively help each other out by providing 
  hints of application usage that pop up at various points when
  using the app
  (e.g., warning: this feature doesn't work as you might expect
           because it actually does this and that, etc.)

* allow users to collaboratively help each other out by providing
  workarounds for bugs, wizards, etc.

* allow discussions, chat, blogs, etc. within the context of an application
  feature

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<




More information about the kde-core-devel mailing list