[Piglit] [Patch RFC] Piglit Segmentation Handler

[Ken Phillis Jr]

On Sat, Feb 23, 2013 at 4:33 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> ----- Original Message -----
>> Ken Phillis Jr <kphillisjr at gmail.com> writes:
>>
>> > I updated the Code for piglit to include windows. I also added the
>> > "standard Copyright" to the new source files... The two new files are
>> > as follows:
>> >
>> > tests/util/piglit-util-sighandler.c
>> > Automatic Backtrace Handling using posix compliant signals. Please
>> > note that register dumps are probably the least portable portion of
>> > the code, and will need changes on a per platform basis
>> >
>> > tests/util/piglit-util-win32.c
>> > Automatic Backtrace Handling on windows. Please note that windows in
>> > general has a much more limited compliance to than most other posix
>> > platforms and thus requires it's own separate file.
>> >
>> >
>> > NOTE: By default if the platform does not have a handler there will be
>> > no system changes. This however, Cannot be kept true for windows. The
>> > changes so far make the software incompatible with versions of windows
>> > made before Windows XP and Windows Server 2003. However, This only
>> > applies if someone builds piglit using Visual Studio 2005 and up.
>>
>> I noted on IRC that I generally don't like this idea.
>>
>> I think that the value in piglit is for Mesa developers that have access
>> to the hardware -- it helps very little to see a backtrace if you don't
>> have access to the machine to directly test your fix, and if you have
>> access to the machine then you just re-run the test under gdb/valgrind,
>> which gets you massively better information and wastes less of your time
>> overall.  In fact, I think that piglit-run.py re-running the test under
>> valgrind when the exit code indicates a crash would be far more useful
>> for the developer than a signal handler.
>>
>> What I definitely don't want to see is signal handling landing in piglit
>> binaries by default.  Maybe someone wants to enable it for
>> ./piglit-run.py in a test farm, but what I'd hate to see is our normal
>> gdb or valgrind workflows changing for the worse.  The experiences I've
>> had with signal handlers and debugging so far has been awful (The X
>> server and SDL, in particular)
>
> I have no preference as far as Linux is concerned. But I thought that signal handlers would do no worse -- at least apitrace's signal handler is transparent -- it simply gives the opportunity to take some action (print some message), and then pass it on to the default handler. That is, gdb, any debugger, will work precisely the same way.
>

For Mac OSX and Linux, This is statement is true, and it still
produces the stock core dump files... It just happens to make note of
some of the machine state in the piglit log before closing out.


For windows, This is also true, and if you want to remove the handler
when a debugger ( like visual studio ) is present, windows has a
single call to make this happen... Just call the IsDebuggerPresent
when the initialization happens.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680345%28v=vs.85%29.aspx

> However on Windows we do need something to avoid halting with dialog boxes. In-process signal handling is one solution. Another is to use out-of-process signal handling, like this tool I wrote/use http://code.google.com/p/jrfonseca/wiki/StackDump
>

On windows, It works really well for my code. The only thing Is it
needs a little testing to make absolutely sure that the signal handler
for abort is functioning properly. For windows, if you do not handle
the abort signal, the program will always produce an error dialog.
Anyways, on windows the debugging functionality does not change and
visual studio displays no difference... Based on my user space tests,
There is absolutely no change. in work flow. The only bit I had
problems with is the fact that Windows 7 by default does not enable
the floating point exceptions for things like divide by zero. However,
the access violation, and integer divide by zero exception handling
works completely as expected.

> For Linux too, I suppose we could enable core dumps by default via ulimit, and then use gdb to output stack trace if any core is generated. I use that on most of the internal test automation I do. It also works quite nicely on MacOSX.
>
> Jose

Mac OSX on intel chips ( and powerpc systems)  there is support to
implement the register dumps... I just don't have a mac to finish
writing the quick handler for also including register output.  This is
the one section of code that is not portable.

for Mac OSX 10.6 to avoid deprecation errors, it's required to use the
header: sys/ucontext.h  or to simply define _XOPEN_SOURCE to an
appropriate version.
Mac OSX manual page for ucontext:
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/ucontext.3.html

Since piglit specifically supports Mac OSX, windows and linux there is
no problems now. However, if a developer is using a system like
netbsd, freebsd, etc... they will need to refer to the system headers
and documentation to find out how to properly handle some of the
missing functionality provided by this patch set.