Preventing App Crashes before Bug Fixes

[Amir Michail]

On Wed, 24 Mar 2004 07:40 pm, Adriaan de Groot wrote:
> I think a big problem will be rollback - and finding the right level of
> abstraction for identifying chunks of code. Consider enabling this
> technology at a C-statement level. So you get a message box:
> 
> 	The statement "assert(!attached())" has caused crashes
> 	63 times in the past with a SIGABRT. Do you want to
> 	execute this statement?
> 
> Per-function might make more sense, but you can invent cases where the
> function level is far too broad to avoid bugs in a meaningful way. Block
> scope it is, then.
> 
> 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?

Hi,

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.

> 
> Now, another problem is the infinite variability of the environment that
> KDE apps run in. I have a really cruddy SiS-chipset based machine (my
> experience is that "really cruddy" is redundant in that sentence, but
> YMMV), where konqueror left unattended will SEGFAULT in a fresh Knoppix
> boot. So, supposing that sends in gobs of reports - does that make the bug
> any more pressing than, say, kgpg's failure to save files (which doesn't
> crash the system, so that's not a fair comparison).

Since such bugs are machine specific, we would not expect to find many such 
bug reports from different users for the same problem.  Perhaps the user 
could set a warning threshold to filter such bug reports out (e.g., if it was 
only reported by 1 person, then ignore it).  Another possibility is to store 
some machine configuration info in the bug report.

BTW, there are many variations on this idea, some of which are less resource 
intensive than others.  

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.  

To reduce resource consumption, you could instead load bug avoidance data 
deltas on application startup and only send data to the server on a crash 
(and normal shutdown perhaps so that the server knows about good and bad 
executions).

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