[Piglit] [Patch RFC] Piglit Segmentation Handler

[Ken Phillis Jr]

I just retested this on windows and this patch set should be considered
critical, because on any recent release of windows ( For example, Windows
Vista and Windows 7) have piglit grind to a halt when running tests because
when a program crashes, windows will always bring up a dialog stating...
"(Insert application name or exe file here) has stopped responding"


On Sat, Feb 23, 2013 at 2:03 PM, Ken Phillis Jr <kphillisjr at gmail.com>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20131029/d363c732/attachment.html>