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

[Alex Bligh <alex@xxxxxxxxxxx>]

Vasil,

> 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 ;-)

OK. It does say it may be unstable after recovery :-) But it shouldn't
do that. What happens if you do it in the debugger (the debugger will
catch the first crash-me-ptr SEGV but you can just continue in which
case it will go into the debugging dialog)? IE debug, crash me ptr,
continue, crash me ptr, then interrupt from the debugger and do a
backtrace to see what's happening.

I suspect this is a FreeBSD thing as it doesn't do it on Linux.
Possibly my reinstating the signal handlers is not working right.
IIRC you are on AMD64 like me, yes?

> 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.

Sure. Some bugs we'll never be able to recover from. We can actually
recover from some forms of stack corruption because that bit of the stack
is never reused (it just sticks another stack on top). We can't recover
from (for instance) stack overflow. But the vast majority of exceptions 
from
Camelot I've seen thrown are dereferencing NULL or corrupted pointers.

Alex