[MOAB-dev] r4602 - MOAB/trunk/test
kraftche at cae.wisc.edu
kraftche at cae.wisc.edu
Wed Mar 16 09:33:27 CDT 2011
Author: kraftche
Date: 2011-03-16 09:33:26 -0500 (Wed, 16 Mar 2011)
New Revision: 4602
Modified:
MOAB/trunk/test/TestUtil.hpp
Log:
be a little more conservative about which signals are trapped for tests. only trap the ones that a test failure is likely to generate
Modified: MOAB/trunk/test/TestUtil.hpp
===================================================================
--- MOAB/trunk/test/TestUtil.hpp 2011-03-16 00:57:17 UTC (rev 4601)
+++ MOAB/trunk/test/TestUtil.hpp 2011-03-16 14:33:26 UTC (rev 4602)
@@ -142,6 +142,14 @@
int init_signal_handlers()
{
int result = 0;
+/* Don't trap these. It is unlikely that a test would ever generate such
+ a signal on its own and trapping them interfers with a user's ability
+ to stop a test. SIGHUP implies that the controlling terminal was closed.
+ If the user does ctrl-C or ctrl-\ (SIGINT and SIGQUIT, respectively) and
+ we trap these then just the current test stops. If we leave the default
+ behavior for them then the whole test suite stops. The latter is likely
+ the desired behavior. SIGTERM is the default signal sent by the 'kill'
+ command.
#ifdef SIGHUP
result += sethandler( SIGHUP );
#endif
@@ -151,6 +159,11 @@
#ifdef SIGQUIT
result += sethandler( SIGQUIT );
#endif
+#ifdef SIGTERM
+ result += sethandler( SIGTERM );
+#endif
+*/
+
#ifdef SIGILL
result += sethandler( SIGILL );
#endif
@@ -169,8 +182,9 @@
#ifdef SIGSEGV
result += sethandler( SIGSEGV );
#endif
-/* Catching these causes problems with mpich2 1.3.1p1 and a test
- should never die due to an uncaught sigusr anyway.
+
+/* Catching these causes problems with mpich2 1.3.1p1 and a
+ test should never receive such a signal anyway.
#ifdef SIGUSR1
result += sethandler( SIGUSR1 );
#endif
@@ -178,15 +192,19 @@
result += sethandler( SIGUSR2 );
#endif
*/
+
+/* Don't trap SIGCHLD. The only way a test should receive
+ such a signal is if it actually forked a child process.
+ That is unlikely, but if it does happen the test probably
More information about the moab-dev
mailing list