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 <kphilli...@gmail.com>wrote: > On Sat, Feb 23, 2013 at 4:33 AM, Jose Fonseca <jfons...@vmware.com> wrote: > > ----- Original Message ----- > >> Ken Phillis Jr <kphilli...@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. >
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
