[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