Re: Some example code for a new crash handler



On Sat, 2002-01-12 at 03:49, Hongl Lai wrote:
> On Sat, 2002-01-12 at 00:59, Havoc Pennington wrote:
> > 
> > Charles Iliya Krempeaux <tnt linux ca> writes: 
> > > Well, how about, instead of saving things over the original files,
> > > you save it as another file name.
> > 
> > You don't understand the problem - the problem is that once you get
> > the SEGV signal, any piece of memory in the program could contain
> > total junk. _Any_ piece. That means there is no way to do anything
> > sane. Say you save your spreadsheet - one of the values in the
> > 100,000-row sheet could be slightly incorrect, for example.
> > 
> > Havoc
> 
> 
> But then there's also a chance that a non-critical part of the memory
> gets corrupt.
> And what do you think is worse? Losing all 300 entries you were working
> at because of a crash, or a file with 200 good entries and 100 bad
> entries?
> 
> If the saved file if totally corrupt, then so be it.
> That is no worse than a crash, where you lose everything.
> But there's a chance that the file won't get corrupt, or only partially
> corrupt.
> We should give users the chance to save what can be saved, don't you
> think?
> 
> I'm not trying to say that programs doesn't have to be bugfree.
> I'm not against autosave.
> But I think it's best if we do everything we can to save:
> fix bugs, implement autosave, AND surpress sigsegv for while to give the
> user some time.

In theory, what you are proposing would be cool. Loosing data is never a
good thing. However, if you had auto-save happen every minute, you would
never loose more than a minute's worth of data.

What I worry about your solution is not the case where half of a file is
corrupted, but where one or two bits is incorrect. As someone already
mentioned, one corrupted cell in a large spreadsheet might never be
noticed. One thing that I would hope we can rely on from our software is
correctness. My understanding is that your patch could remove that
guarentee. (At least to those who don't understand that the emercency
backup file is not to be relied upon.)

What I wonder is this: Could things be written to do an emergency save
in the case where a component of a program dies but where the component
storing the data did not?

--Ben

Attachment: pgp3LYscwMHkf.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]