Paulo Zanoni a16ebccaee igt_core: zero exit_handler_count before forking
If we don't reset exit_handler_count before forking, we may have a
case where the forked process is killed before it even does
"exit_handler_count = 0": in that case, it is still finishing forking.
When that happens, we may end up calling our exit handlers. On the
specific bug I'm investigating, we call igt_reset_connnectors(), which
ends up in a deadlock inside malloc_atfork. If we attach gdb to the
forked process and get a backtrace, we have:

(gdb) bt
0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
1  0x00007f15634d36bf in _L_lock_10524 () from /lib/x86_64-linux-gnu/libc.so.6
2  0x00007f15634d12ef in malloc_atfork (sz=139729840351352, caller=<optimized out>) at arena.c:181
3  0x00007f15640466a1 in drmMalloc () from /usr/lib/x86_64-linux-gnu/libdrm.so.2
4  0x00007f1564049ad7 in drmModeGetResources () from /usr/lib/x86_64-linux-gnu/libdrm.so.2
5  0x0000000000408f84 in igt_reset_connectors () at igt_kms.c:1656
6  0x00000000004092dc in call_exit_handlers (sig=15) at igt_core.c:1130
7  fatal_sig_handler (sig=15) at igt_core.c:1154
8  <signal handler called>
9  0x00007f15634cce60 in ptmalloc_unlock_all2 () at arena.c:298
10 0x00007f156350ca3f in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:188
11 0x000000000040a029 in __igt_fork_helper (proc=proc@entry=0x610fc4 <signal_helper>) at igt_core.c:910
12 0x000000000040459d in igt_fork_signal_helper () at igt_aux.c:110
13 0x0000000000402ab7 in __real_main63 () at bug.c:76
14 0x000000000040296e in main (argc=<optimized out>, argv=<optimized out>) at bug.c:63

After doing some searches for "stuck at malloc_atfork", it seems to me
we probably shouldn't be doing any malloc calls at this point of the
code, so the best way to do that is to make sure we can't really run
the exit handlers.

So on this patch, instead of resetting the exit handlers after
forking, we reset them before forking, and then restore the original
value on the parent process.

I can reproduce this problem by running "./kms_flip --run-subtest
2x-flip-vs-modeset" under an infinite loop. Usually after a few
hundred calls, we end up stuck on the deadlock mentioned above. QA
says this problem happens every time, but I'm not sure what is the
difference between our environments that makes the race condition so
much easier for them.

The kms_flip.c problem can be considered a regression introduced by:
commit eef768f283466b6d7cb3f08381f72ccf3951dc99
Author: Thomas Wood <thomas.wood@intel.com>
Date:   Wed Jun 18 14:28:43 2014 +0100
    tests: enable extra connectors in kms_flip and kms_pipe_crc_basic

even though this commit is not the one that introduced the real
problem.

It is also possible to reproduce this problem with a few modifications
to template.c:
  - Add a call to igt_enable_connectors() inside the first fixture.
  - Add igt_fork_signal_helper() and igt_stop_signal_helper() calls
    around subtest B.

Note that the crucial piece is that the parent actively kills helper
children, and if we skip tests this can happen _really_ fast. See e.g.

commit a031a1bf93b828585e7147f06145fc5030814547
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Sep 13 16:43:22 2013 +0200

    lib/drmtest: ducttape over fork race

for past hilarity in this area.

Cc: Thomas Wood <thomas.wood@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81367
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-04 10:35:21 +02:00
2014-03-26 18:50:27 +01:00
2013-06-23 16:13:05 -07:00
2013-09-13 15:33:50 +01:00
2014-07-23 16:43:05 +01:00
2014-04-24 13:49:20 +01:00
2014-03-11 17:19:47 +01:00
2012-01-04 10:47:10 +01:00

This is a collection of tools for development and testing of the Intel DRM
driver.  There are many macro-level test suites that get used against our
driver, including xtest, rendercheck, piglit, and oglconform, but failures
from those can be difficult to track down to kernel changes, and many require
complicated build procedures or specific testing environments to get useful
results.

Thus, intel-graphics-tools was a project I started to collect some low-level
tools I intended to build.

benchmarks/
	This should be a collection of useful microbenchmarks.  The hope is
	that people can use these to tune some pieces of DRM code in relevant
	ways.

	The benchmarks require KMS to be enabled.  When run with an X Server
	running, they must be run as root to avoid the authentication
	requirement.

	Note that a few other microbenchmarks are in tests (like gem_gtt_speed).

tests/
	This is a set of automated tests to run against the DRM to validate
	changes.  Hopefully this can cover the relevant cases we need to
	worry about, including backwards compatibility.

	The test suite can be run using the run-tests.sh script available in
	the scripts directory. Piglit is used to run the tests and can either
	be installed from your distribution (if available), or can be
	downloaded locally for use with the script by running:

	./scripts/run-tests.sh -d

	run-tests.sh has options for filtering and excluding tests from test
	runs:

	  -t <regex>      only include tests that match the regular expression
	  -x <regex>      exclude tests that match the regular expression

	Useful patterns for test filtering are described in
	tests/NAMING-CONVENTION and the full list of tests and subtests can be
	produced by passing -l to the run-tests.sh script.

	Results are written to a JSON file and an HTML summary can also be
	created by passing -s to the run-tests.sh script. Further options are
	are detailed by using the -h option.


	If not using the script, piglit can be obtained from:

	git://anongit.freedesktop.org/piglit

	There is no need to build and install piglit if it is only going to be
	used for running i-g-t tests.

	Set the IGT_TEST_ROOT environment variable to point to the tests
	directory, or set the path key in the "igt" section of piglit.conf to
	the intel-gpu-tools root directory.

	The tests in the i-g-t sources need to have been built already. Then we
	can run the testcases with (as usual as root, no other drm clients
	running):

	piglit-sources # ./piglit run igt <results-file>

	The testlist is built at runtime, so no need to update anything in
	piglit when adding new tests. See

	piglit-sources $ ./piglit run -h

	for some useful options.

	Piglit only runs a default set of tests and is useful for regression
	testing. Other tests not run are:
	- tests that might hang the gpu, see HANG in Makefile.am
	- gem_stress, a stress test suite. Look at the source for all the
	  various options.
	- testdisplay is only run in the default mode. testdisplay has tons of
	  options to test different kms functionality, again read the source for
	  the details.

	When creating new tests or subtests please read and follow
	tests/NAMING-CONVENTION.

lib/
	Common helper functions and headers used by the other tools.

man/
	Manpages, unfortunately rather incomplete.

tools/
	This is a collection of debugging tools that had previously been
	built with the 2D driver but not shipped.  Some distros were hacking
	up the 2D build to ship them.  Instead, here's a separate package for
	people debugging the driver.

	These tools generally must be run as root, safe for the ones that just
	decode dumps.

tools/quick_dump
	Quick dumper is a python tool built with SWIG bindings to
	important libraries exported by the rest of the tool suite. The tool
	itself is quite straight forward, and should also be a useful example
	for others wishing to write python based i915 tools.

	Note to package maintainers: It is not recommended to package
	this directory, as the tool is not yet designed for wide usage. If the
	package is installed via "make install" the users will have to set
	their python library path appropriately. Use --disable-dumper

debugger/
	This tool is to be used to do shader debugging. It acts like a
	debug server accepting connections from debug clients such as
	mesa. The connections is made with unix domain sockets, and at some
	point it would be nice if this directory contained a library for
	initiating connections with debug clients..

	The debugger must be run as root: "sudo debugger/eudb"

docs/
	Thus far just contains the autogenerated intel-gpu-tools libraries
	reference documenation in docs/reference/ You need to have the gtk doc
	tools installed to generate this API documentation.

	To regenerate the html files when updating documentation, use:

	$ make clean -C docs && make -C docs

	If you've added/changed/removed a symbol or anything else that changes
	the overall structure or indexes, this needs to be reflected in
	intel-gpu-tools-sections.txt. Entirely new sections will also need to be
	added to intel-gpu-tools-docs.xml in the appropriate place.

DEPENDENCIES
	This is a non-exchaustive list of package dependencies required for
	building everything:

	libpciaccess-dev
	libdrm-dev
	xutils-dev
	libcairo2-dev
	swig2.0
	libpython3.3-dev
	x11proto-dri2-dev
	gtk-doc-tools
Description
No description provided
Readme 18 MiB
Languages
C 95.5%
Yacc 2.5%
Makefile 0.5%
Shell 0.5%
Lex 0.3%
Other 0.6%