Fail tests if still running after 5 minutes
When diagnosing build-time tests that get stuck, such as the one in !12 (closed), it's helpful for the test to abort after some reasonable timeout (leaving a core dump and any previous log output), rather than relying on some external process to kill the entire build after a longer arbitrary timeout like an hour (which would also terminate whatever test harnesses, logging, etc. are in use, limiting the available diagnostics).
The implementation of egg_tests_set_fatal_timeout() is heavily based on code that I contributed to dbus. The choice of a 5 minute timeout is completely arbitrary (dbus mostly uses 1 minute): please adjust up or down as appropriate.
If a particular test case is known to be particularly slow, you can call egg_tests_set_fatal_timeout() in setup() and/or teardown() to reset the timer, effectively providing a per-test-case timeout. I haven't done this in any of the tests.
When running under valgrind or qemu, or on a particularly slow CPU, the environment variable TEST_FATAL_TIMEOUT_MULTIPLIER can be set to an integer to multiply all of these timeouts. For example, TEST_FATAL_TIMEOUT_MULTIPLIER=10 has worked well when running dbus tests under valgrind, and 20 works well for qemu-system-risc64.
I used this while debugging the issue that led to !12 (closed). At some point I'll probably contribute something similar to GLib, but that will be new API, so it won't be available without a new GLib dependency.
Please adjust the timeout based on what you think is a reasonable maximum time for a test to take (and then perhaps double it, to account for slower architectures like ARM and MIPS).