Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8278470

[LOOM] JTREG wrapper causes some tests to fail due to unexpected exception handler

XMLWordPrintable

      Loom has introduced nsk.share.MainWrapper for allowing nsk tests to run the main test thread and debuggee thread using a vthread instead of a platform thread. Use of this wrapper is controlled in the source using the main.wrapper property. It is set on the command line using JTREG_MAIN_WRAPPER.

      If main.wrapper is set to Virtual, then test threads are wrapped in a vthread. If it is set to anything else then a platform thread is used. If not set at all then nsk.share.MainWrapper is not used, and platform threads are used. This "wrapping" changes how test threads are invoked. Rather then just spawning a platform thread which uses the "main" method as the entrypoint, reflection is used to invoke the "main" method:

              Runnable task = () -> {
                  try {
                      Class<?> c = Class.forName(className);
                      Method mainMethod = c.getMethod("main", new Class[] { String[].class });
                      mainMethod.setAccessible(true);
                      mainMethod.invoke(null, new Object[] { classArgs });
                  } catch (InvocationTargetException e) {
                      e.printStackTrace();
                      ue.set(e.getCause());
                  } catch (Exception e) {
                      e.printStackTrace();
                  }
              };

              Thread t;
              if (wrapperName.equals("Virtual")) {
                  t = unstartedVirtualThread(task);
              } else {
                  t = new Thread(task);
              }

      The use of reflection in this manner introduces two exception handlers. One is in Method.invoke() and the other is in the above code. There are a few debugger tests that expect there to be no exception handler in place when the test is run. These tests intentionally trigger an exception, and when the Exception event is delivered, they expect for it to not contain a "catch location". However, when invoked using the above code, there is a "catch location", and the tests fails as a result. Here is a list of tests:

      vmTestbase/nsk/jdb/uncaught_exception/uncaught_exception002/uncaught_exception002.java
      vmTestbase/nsk/jdb/where/where005/where005.java
      vmTestbase/nsk/jdi/ExceptionEvent/catchLocation/location002/TestDescription.java

      com/sun/jdi/ExceptionEvents.java
      com/sun/jdi/RedefineCrossStart.java

      For the two jdb tests, the "Exception occurred: java.lang.NullPointerException (uncaught)" message is missing from the jdb output because the exception is caught. For the jdi test, the failure is a bit more explicit in that the test complains about the unexpected "catchLocation" for the exception.

            Unassigned Unassigned
            cjplummer Chris Plummer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: