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

[Vasil Dimov <vd@xxxxxxxxxxx>]

On Thu, Jun 08, 2006 at 04:32:38PM +0100, Alex Bligh wrote:
> 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.

After crash-me-ptr is selected for a second time a sigsegv is delivered
(of course) and after I type `continue' in the debugger a sigsegv is
immediately delivered again and I am again at the (gdb) prompt, after
typing `continue' this just repeats:

...
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x085d1fbc in wxFontEnumerator::OnFontEncoding ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x085d1fbc in wxFontEnumerator::OnFontEncoding ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x085d1fbc in wxFontEnumerator::OnFontEncoding ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x085d1fbc in wxFontEnumerator::OnFontEncoding ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x085d1fbc in wxFontEnumerator::OnFontEncoding ()
(gdb)

I think this explains the infinite loop and the CPU load when XaraLX is
executed outside a debugger.

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

Yes, I initially discovered this behavior on amd64, but I just tested on
i386 and it's the same. Probably it is something related to signal
handling/delivery.

Anyway I think there are more important things to bother about than what
happens after the program is crashed twice :-)

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

I agree.

-- 
Vasil Dimov
gro.DSBeerF@dv

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