[Piglit] [Patch RFC] Piglit Segmentation Handler

[Jose Fonseca]

----- Original Message -----
> On Mon, Feb 18, 2013 at 10:40 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> > I think this is a great idea.
> >
> > Concerning Windows, I don't have time to test myself now, but FWIW, feel
> > free to lift inspiration/code from apitrace's exception handler:
> > https://github.com/apitrace/apitrace/blob/master/common/os_win32.cpp#L248
> > I know it works very well.
> >
> 
> I did find some of that useful. I also see that I probably *should*
> add a function to remove the handlers for the cases when a particular
> host system does not support automatically reverting things to default
> state. However, From what I can see, Windows automatically uses
> default handlers.

apitrace needs to be particularly careful to avoid interfereing with apps' exception handlers, but here piglit is the main app, and I don't think we rely on signals anywhere, so it probably doesn't matter.

> > However this is not enough to make piglit on windows 100% handsfree --
> > because assertion failures / errors on windows often create an interactive
> > dialog box, the only way to be 100% sure the test won't hang is to have
> > the piglit python framework periodically search for dialog boxes...
> >
> > Jose
> >
> 
> SetErrorMode is what you use to simply enable/disable error
> Functionality. SEM_NOGPFAULTERRORBOX is the exact flag that needs to
> be used to disable the crash dialog.

This helps, many system error messages honor that. But I believe that MSVCRT assertion failures and some other error messages can still pop up.

> As for other things, the best way to capture crash backtraces that I
> can find is to use the AddVectoredExceptionHandler ( and
> RemoveVectoredExceptionHandler ) functions over the other functions (
> SetUnhandledExceptionFilter, Signal, and _set_se_translator ). That
> said, Currently I only have backtraces generated for the following
> exceptions...
> 
> EXCEPTION_FLT_DIVIDE_BY_ZERO
> EXCEPTION_INT_DIVIDE_BY_ZERO
> EXCEPTION_ACCESS_VIOLATION

Well, in this case (unlike apitrace), we known we are the only exception handler, so my understanding is that any exception will be fatal.

> That said, Here's some of the documentation I'm using to figure out
> what exceptions to handle/use...


> MSDN - EXCEPTION_RECORD Structure
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363082%28v=vs.85%29.aspx
> 
> 
> MSDN - SetErrorMode documentation
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680621%28v=vs.85%29.aspx
> 
> MSDN - AddVectoredExceptionHandler
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679274%28v=vs.85%29.aspx
> MSDN - RemoveVectoredExceptionHandler
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680571%28v=vs.85%29.aspx
> 
> As for backtracing, I am using SymFromAddr, SymGetLineFromAddr64, and
> SymInitialize from dbghelp (
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679309%28v=vs.85%29.aspx
> ), and CaptureStackBackTrace (
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb204633%28v=vs.85%29.aspx
> )

Note that dbgjelp.dll is not bundled with Windows. I'm not sure what are the redistrbutions conditions. We might want to dynamically link in runtime, to avoid introducing a dependency.

This might also interest you:

  http://code.google.com/p/google-breakpad/

> NOTE: I have not yet tested the backtrace capture on a real driver
> with windows, but with an in-program crash the capture works well
> enough to guarantee that piglit will get a "Crash" result and
> backtrace before the program closes out

This is already a nice improvement.

Jose