< prev index next >

test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java

Print this page
rev 59189 : imported patch hotspot


  32 import jdk.test.lib.process.ProcessTools;
  33 
  34 /*
  35  * @test
  36  * @bug 8166944
  37  * @summary Hanging Error Reporting steps may lead to torn error logs
  38  * @modules java.base/jdk.internal.misc
  39  * @library /test/lib
  40  * @requires (vm.debug == true) & (os.family != "windows")
  41  * @run driver TimeoutInErrorHandlingTest
  42  * @author Thomas Stuefe (SAP)
  43  */
  44 
  45 public class TimeoutInErrorHandlingTest {
  46 
  47     public static final boolean verbose = System.getProperty("verbose") != null;
  48     // 16 seconds for hs_err generation timeout = 4 seconds per step timeout
  49     public static final int ERROR_LOG_TIMEOUT = 16;
  50 
  51     public static void main(String[] args) throws Exception {
  52 
  53         int error_log_timeout = ERROR_LOG_TIMEOUT;
  54         if ("SunOS".equals(System.getProperty("os.name"))) {
  55             // Give Solaris machines 3X as much time:
  56             error_log_timeout *= 3;
  57         }
  58 
  59         /* Start the VM and let it crash. Specify TestUnresponsiveErrorHandler which will
  60          * let five subsequent error reporting steps hang. The Timeout handling triggered
  61          * by the WatcherThread should kick in and interrupt those steps. In theory, the
  62          * text "timeout occurred during error reporting in step .." (the little timeouts)
  63          * should occur in the error log up to four times, followed by the final big timeout
  64          * "------ Timeout during error reporting after xx s. ------"
  65          *
  66          * Note that there are a number of uncertainties which make writing a 100% foolproof
  67          * test challenging. The time the error reporting thread takes to react to the
  68          * timeout triggers is unknown. So it is difficult to predict how many little timeouts
  69          * will be visible before the big timeout kicks in. Also, once the big timeout hits,
  70          * error reporting thread and Watcherthread will race. The former writes his last
  71          * message to the error logs and flushes, the latter waits 200ms and then exits the
  72          * process without further synchronization with the error reporting thread.
  73          *
  74          * Because of all this and the desire to write a bullet proof test which does
  75          * not fail sporadically, we will not test for the final timeout message nor for all
  76          * of the optimally expected little timeout messages. We just test for two of the
  77          * little timeout messages to see that repeated timeout handling is basically working.
  78          */
  79 
  80         ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(
  81             "-XX:+UnlockDiagnosticVMOptions",
  82             "-Xmx100M",
  83             "-XX:ErrorHandlerTest=14",
  84             "-XX:+TestUnresponsiveErrorHandler",
  85             "-XX:ErrorLogTimeout=" + error_log_timeout,
  86             "-XX:-CreateCoredumpOnCrash",
  87             "-version");
  88 
  89         OutputAnalyzer output_detail = new OutputAnalyzer(pb.start());
  90 
  91         if (verbose) {
  92             System.err.println("<begin cmd output>");
  93             System.err.println(output_detail.getOutput());
  94             System.err.println("<end cmd output>");
  95         }
  96 
  97         // we should have crashed with a SIGSEGV
  98         output_detail.shouldMatch("# A fatal error has been detected by the Java Runtime Environment:.*");
  99         output_detail.shouldMatch("# +(?:SIGSEGV|SIGBUS|EXCEPTION_ACCESS_VIOLATION).*");
 100 
 101         // VM should have been aborted by WatcherThread
 102         output_detail.shouldMatch(".*timer expired, abort.*");
 103 
 104         // extract hs-err file
 105         String hs_err_file = output_detail.firstMatch("# *(\\S*hs_err_pid\\d+\\.log)", 1);




  32 import jdk.test.lib.process.ProcessTools;
  33 
  34 /*
  35  * @test
  36  * @bug 8166944
  37  * @summary Hanging Error Reporting steps may lead to torn error logs
  38  * @modules java.base/jdk.internal.misc
  39  * @library /test/lib
  40  * @requires (vm.debug == true) & (os.family != "windows")
  41  * @run driver TimeoutInErrorHandlingTest
  42  * @author Thomas Stuefe (SAP)
  43  */
  44 
  45 public class TimeoutInErrorHandlingTest {
  46 
  47     public static final boolean verbose = System.getProperty("verbose") != null;
  48     // 16 seconds for hs_err generation timeout = 4 seconds per step timeout
  49     public static final int ERROR_LOG_TIMEOUT = 16;
  50 
  51     public static void main(String[] args) throws Exception {







  52         /* Start the VM and let it crash. Specify TestUnresponsiveErrorHandler which will
  53          * let five subsequent error reporting steps hang. The Timeout handling triggered
  54          * by the WatcherThread should kick in and interrupt those steps. In theory, the
  55          * text "timeout occurred during error reporting in step .." (the little timeouts)
  56          * should occur in the error log up to four times, followed by the final big timeout
  57          * "------ Timeout during error reporting after xx s. ------"
  58          *
  59          * Note that there are a number of uncertainties which make writing a 100% foolproof
  60          * test challenging. The time the error reporting thread takes to react to the
  61          * timeout triggers is unknown. So it is difficult to predict how many little timeouts
  62          * will be visible before the big timeout kicks in. Also, once the big timeout hits,
  63          * error reporting thread and Watcherthread will race. The former writes his last
  64          * message to the error logs and flushes, the latter waits 200ms and then exits the
  65          * process without further synchronization with the error reporting thread.
  66          *
  67          * Because of all this and the desire to write a bullet proof test which does
  68          * not fail sporadically, we will not test for the final timeout message nor for all
  69          * of the optimally expected little timeout messages. We just test for two of the
  70          * little timeout messages to see that repeated timeout handling is basically working.
  71          */
  72 
  73         ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(
  74             "-XX:+UnlockDiagnosticVMOptions",
  75             "-Xmx100M",
  76             "-XX:ErrorHandlerTest=14",
  77             "-XX:+TestUnresponsiveErrorHandler",
  78             "-XX:ErrorLogTimeout=" + ERROR_LOG_TIMEOUT,
  79             "-XX:-CreateCoredumpOnCrash",
  80             "-version");
  81 
  82         OutputAnalyzer output_detail = new OutputAnalyzer(pb.start());
  83 
  84         if (verbose) {
  85             System.err.println("<begin cmd output>");
  86             System.err.println(output_detail.getOutput());
  87             System.err.println("<end cmd output>");
  88         }
  89 
  90         // we should have crashed with a SIGSEGV
  91         output_detail.shouldMatch("# A fatal error has been detected by the Java Runtime Environment:.*");
  92         output_detail.shouldMatch("# +(?:SIGSEGV|SIGBUS|EXCEPTION_ACCESS_VIOLATION).*");
  93 
  94         // VM should have been aborted by WatcherThread
  95         output_detail.shouldMatch(".*timer expired, abort.*");
  96 
  97         // extract hs-err file
  98         String hs_err_file = output_detail.firstMatch("# *(\\S*hs_err_pid\\d+\\.log)", 1);


< prev index next >