[Piglit] [Patch RFC] Piglit Segmentation Handler

[Jose Fonseca]

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

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

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