[Piglit] [Patch RFC] Piglit Segmentation Handler

[Ken Phillis Jr]

On Wed, Feb 20, 2013 at 1:36 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> ----- 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.
>

I figured as much. So far it's working well on the tests I use.
However, I also checked with wine and found that the tests did not go
completely as expected... The code compiled with mingw64 and running
with wine did not mix well... unimplemented code and it ultimately
crashes wine.
>> > 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.
>

Wine does not honor this semantic since I actually get a crash report with this.

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


Based on my testing with MSVC, the if you run the program in the
debugger,  the debugger will break at the actual exception site so
things are not as bad.
>> 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.
>

I'm not worried about dbhelp.dll issues... Microsoft specifically
includes it with all copies of Windows XP and up, and based on their
website, It appears that redistribution of this library is allowed as
long as steps are taken to prevent usage on non-windows platforms...
However, This may be a minor issue since on most development machines
probably have installed a copy of dbghelp.dll that  is bundled with
visual studio, or you can simply recommend that users install the
"Debugging Tools for Windows" when they attempt to run the program.

MSDN: DbgHelp Versions ( Windows ):
http://msdn.microsoft.com/en-us/library/ms679294%28VS.85%29.aspx


> 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

I went ahead and looked at this code. It depends on imagehlp.dll...
And this is not redistributable.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680321%28v=vs.85%29.aspx