Subject: Re: MS Word does NOT do this!
From: Tim LaDuca (mail@timl.org)
Date: Sun Aug 13 2000 - 00:32:20 CDT
sam th wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 9 Aug 2000, Martin Sevior wrote:
>
> >
> >
> > On 9 Aug 2000, Tim LaDuca wrote:
> >
> > > changes are lost. How is it possible for a application that has
> > > basically crashed to still save its open document? Being a long time
> > > Word user I find this completely amazing.
> > >
> >
> > What happens is that the kernal detects that a program is attempting
> > to access a region of memory it is not allowed to. It sends a signal to
> > the running application informing the application of this problem. Now
> > this is a very bad thing for the application to be doing and means
> > something has gone gone horribally wrong somewhere. Abi intercepts this
> > signal and attempts to save the file. If abi has not become too corrupted
> > this works.
> >
>
> Almost always, this means that a pointer was either unitialized before
> access, or improperly initialized. And usually, this isn't a pointer
> neccessary for the save operation, so if we just forget about it, and save
> and then abort(), life should be fine.
>
> > I've actually managed to get abi into an infinite loop of segfault -
> > attempt to save file - segfault - attempt to save file - segfault. etc.
> >
> > I guess we need a counter to give up after too many segfault signals.
> >
>
> This *should not* happen. We are not supposed to be trapping segfault's
> in the segfault handler. Theoretically, the following line should prevent
> this (ap_UnixApp.cpp)
>
> [873] sa.sa_flags = SA_NODEFER | SA_RESETHAND; // Don't handle nested
> signals
>
> However, it appears I will have to read some more specs about
> this. Thanks for the heads up.
FWIW, I had an AbiWord crash in which 40 backups were saved, each one
with an additional .bak extension, so the 40th file had 40 extentions!
:-)
TimL
This archive was generated by hypermail 2b25 : Sun Aug 13 2000 - 00:33:12 CDT