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

TEST_BUG: intermittent StackOverflow in RMI bench/serial test

    Details

    • Subcomponent:
    • Resolved In Build:
      b01
    • Verification:
      Not verified

      Description

      TESTFAIL:java/rmi/reliability/benchmark/bench/serial/Main.java

      A StackOverflow error occasionally occurs when running this test. This test was recently converted from a shell script test to a Java test. There may be some subtlety in the different execution environments that causes this failure. As far as I know the test had been running for years as a shell script without these problems.

      Partial stack trace:

      java.lang.StackOverflowError
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      (...snip...)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      at bench.serial.ClassDesc.run(ClassDesc.java:104)
      at bench.BenchInfo.runBenchmark(BenchInfo.java:57)
      at bench.Harness.runBenchmarks(Harness.java:213)
      at bench.serial.Main.runBenchmarks(Main.java:295)
      at bench.serial.Main.main(Main.java:139)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:483)
      at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
      at java.lang.Thread.run(Thread.java:744)

        Issue Links

          Activity

          Hide
          tyan Tristan Yan (Inactive) added a comment -
          Root Cause:
          By looking at the log, ClassDesc will recursive load 50 classes, and overflow was thrown on 50th class load. This is a real stack overflow.

          Suggested Fix:
          adding java option -Xss:2m to support bigger stack space.


          Show
          tyan Tristan Yan (Inactive) added a comment - Root Cause: By looking at the log, ClassDesc will recursive load 50 classes, and overflow was thrown on 50th class load. This is a real stack overflow. Suggested Fix: adding java option -Xss:2m to support bigger stack space.
          Show
          tyan Tristan Yan (Inactive) added a comment - Code review sent to open alias: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024035.html
          Hide
          smarks Stuart Marks added a comment -
          I had raised the question of why this StackOverflow is manifesting itself now, after the conversion from a shell script test to a Java test. Was there some other change in the execution environment of the test that caused this?

          Tristan did some investigation and found that the shell script test could also get a StackOverflow error, but it would still report the test as passing! The reason is that the shell script invoked the test JVM in the following manner:

          $TESTJAVA/bin/java \
              ${TESTVMOPTS} \
              -cp $TESTCLASSES \
              bench.serial.Main \
              -c $TESTSRC/bench/serial/jtreg-config &

          Specifically, it ran the JVM in the background. This will still cause jtreg to wait for the JVM subprocess to exit, but it will discard the exit status of the JVM subprocess!! The StackOverflow would be captured in the log, but the top-level script would still exit with status zero, indicating success.

          Yet another testing pitfall with shell script tests.

          Running the JVM in the background is probably a holdover from this script having been derived from the RMI benchmark test, also a shell script. In that script, two JVMs are necessary, one run in the background as the RMI server, and the other in the foreground as the RMI client. When that script was edited into the serial benchmark test, only one JVM was necessary, and the command to run the RMI server in the background was retained and edited, along with it being run in the background.

          The loading of 50 nested classes does take a fair amount of stack space. I did some experiments and found that the shell script test would throw StackOverflow with anything less than -Xss552k, whereas the Java test would throw StackOverflow with anything less than -Xss560k (at least in my environment). This is a negligible difference, probably attributable to the presence of the jtreg agent in the test JVM. (Note that -Xss values are honored only if they are an exact multiple of 8k, at least in my environment.)

          In any case the StackOverflow was probably there all along. It was concealed by a botched shell script, and it only appeared when the shell script was converted to Java.
          Show
          smarks Stuart Marks added a comment - I had raised the question of why this StackOverflow is manifesting itself now, after the conversion from a shell script test to a Java test. Was there some other change in the execution environment of the test that caused this? Tristan did some investigation and found that the shell script test could also get a StackOverflow error, but it would still report the test as passing! The reason is that the shell script invoked the test JVM in the following manner: $TESTJAVA/bin/java \     ${TESTVMOPTS} \     -cp $TESTCLASSES \     bench.serial.Main \     -c $TESTSRC/bench/serial/jtreg-config & Specifically, it ran the JVM in the background. This will still cause jtreg to wait for the JVM subprocess to exit, but it will discard the exit status of the JVM subprocess!! The StackOverflow would be captured in the log, but the top-level script would still exit with status zero, indicating success. Yet another testing pitfall with shell script tests. Running the JVM in the background is probably a holdover from this script having been derived from the RMI benchmark test, also a shell script. In that script, two JVMs are necessary, one run in the background as the RMI server, and the other in the foreground as the RMI client. When that script was edited into the serial benchmark test, only one JVM was necessary, and the command to run the RMI server in the background was retained and edited, along with it being run in the background. The loading of 50 nested classes does take a fair amount of stack space. I did some experiments and found that the shell script test would throw StackOverflow with anything less than -Xss552k, whereas the Java test would throw StackOverflow with anything less than -Xss560k (at least in my environment). This is a negligible difference, probably attributable to the presence of the jtreg agent in the test JVM. (Note that -Xss values are honored only if they are an exact multiple of 8k, at least in my environment.) In any case the StackOverflow was probably there all along. It was concealed by a botched shell script, and it only appeared when the shell script was converted to Java.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/df79231a1e18
          User: smarks
          Date: 2014-01-04 04:53:26 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/df79231a1e18 User: smarks Date: 2014-01-04 04:53:26 +0000
          Hide
          smarks Stuart Marks added a comment -
          The fix for JDK-7190106 converted the serialization benchmark from a shell script to Java, which exposed this problem.
          Show
          smarks Stuart Marks added a comment - The fix for JDK-7190106 converted the serialization benchmark from a shell script to Java, which exposed this problem.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/df79231a1e18
          User: lana
          Date: 2014-01-15 02:08:46 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/df79231a1e18 User: lana Date: 2014-01-15 02:08:46 +0000

            People

            • Assignee:
              tyan Tristan Yan (Inactive)
              Reporter:
              smarks Stuart Marks
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: