Re: [XaraXtreme-dev] Handling SEGV etc. and recovering

[Vasil Dimov <vd@xxxxxxxxxxx>]

On Fri, May 19, 2006 at 05:25:57PM +0100, Alex Bligh wrote:
> Vasil,
> 
> Vasil Dimov wrote:
> 
> >If the SEGV signal did not originate from a kill(2) invocation the
> >program behaviour after catching it is undefined.
> >
> >You certainly do not want this. It can lead to infinite loops, memory
> >exhaustion or even data damage and loss.
> >
> >SIGSEGV cannot be over-lived: the app should better quit just
> >like any other app does.
> 
> What it does is bring up a message box if it can. It looks very
> carefully for infinite loops, memory exhaustion etc., and if it
> finds them, it will just exit (it uses a recursion counter).
> 
> It then brings up an error box either telling the user an exception
> has occurred and it's going to quit (hopefully giving them some
> detail about where - I'm just working on that bit), or gives
> them a warning telling them something dreadful has happened, we
> are not sure whether we can proceed, and they should save their
> work under a different filename.
> 
> I've tested it pretty extensively here and haven't got much more
> nasty to happen than the menus not appear.
> 
> I still think that is better than the program disappearing
> with no explanation. In 95% of cases it seems the user will be
> able to save their work.
> 
> Give it a try and see if it works for you (try the "Crash Me"
> options from the menu - the Ptr one does a null pointer
> dereference, the render one does a null pointer dereference
> from the middle of the rendering code).
> 

Hi Alex,

Finally I got some time to take a look at this.

This is what I have found - after selecting the "crash me ptr" and
"continue" afterwards the application seems to work fine - I can draw
a rectangle. After selecting "crash me ptr" again (without closing the
application after the first "crash me ptr") the whole XaraLX freezes -
the menus and buttons are not responding and the xaralx executable
appears on the top of the processes list, eating 100% of the CPU.
I have to kill(1) the application.

This what my testing showed ;-)

Btw:
Dereferencing a NULL pointer (in exceptio.cpp: GlobalByte = *lpByte,
where lpByte is NULL) does not really damage anything, it just raises
SIGSEGV.
More serious crash cat be simulated like this:

(heap overflow)
char *p;
p = (char *)malloc(16);
for (;;)
	p++ = 42;

or stack overflow:

char *p;
char s[16];
p = s;
for (;;)
	p++ = 42;

This can really cause things to screw up and is not less realistic
than a NULL poiner dereference.

-- 
Vasil Dimov
gro.DSBeerF@dv

Testing can show the presence of bugs, but not their absence.
                -- Edsger W. Dijkstra