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

Passing illegal value for JFR startupargs causes SEGV or errors



    • Type: Bug
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 12, 13, 14, 15, 16, 17
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
    • OS:
      linux_ubuntu, windows


      At least 2 JFR tests fail with the same root cause: when passing illegal/unacceptable value for JFR startup arguments, the expected behavior is to exit with code -1. Instead, the JVM crashes with Segmentation Fault, and odd looking stack (possible stack corruption?)

      Tests that fail:
          jdk/jfr/startupargs/TestStartName.java (passing a numeric value for the 'name' parameter)
          jdk/jfr/startupargs/TestMemoryOptions.java (passing illegal value for memory buffer size, e.g. under the minimum acceptable value)

      The following test failed due to an exception on Linux X64
      in the fastdebug config using jdk-12+22 bits:


      The test only failed in 1 of 3 'fastdebug' bits runs so I'm
      tagging this bug as intermittent. It did not fail at all in the
      'release' or 'slowdebug' bits runs.

      ============== Initial analysis
       The test intentionally sets the numeric value for the JFR recording name (numeric values are not acceptable), and expects the JVM to fail with exit 1.
      However, JVM crashes with Segmentation fault (exit code 139 commonly used for segmentation fault). The attached zip files contain hs_err files. Based on these files, the stack pointer is random and strange value (in one case it is 0x0000000000000065, other cases somewhere in libc). Possible stack corruption?

      Here is a snippet from the log file:

       stdout: [Name of recording can't be numeric
      Error occurred during initialization of VM
      Failure when starting JFR on_vm_start
       stderr: []
       exitValue = 139

      java.lang.RuntimeException: Expected to get exit value of [1]

              at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:419)
              at jdk.jfr.startupargs.TestStartName.testName(TestStartName.java:57)
              at jdk.jfr.startupargs.TestStartName.main(TestStartName.java:68)
              at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.base/java.lang.reflect.Method.invoke(Method.java:567)
              at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
              at java.base/java.lang.Thread.run(Thread.java:835)

      JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [1]

      JavaTest Message: shutting down test

      STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [1]

      The test case is expected to fail with an exit code of "1", but instead failed
      with an exit code of "139". That exit code make me wonder if the test crashed,
      but the test run directories have been already cleaned up. (This is run #1 of 3.)


        1. hs_err_pid17662.log
          109 kB
        2. hs_err_pid24712.log
          107 kB
        3. hs_err_pid5555.log
          106 kB
        4. jdk-12+22_linux.8214685.zip
          3 kB
        5. jdk-13+12_linux.8214685.zip
          20 kB
        6. jdk-13+30_linux.8214685.zip
          21 kB
        7. jdk-14+19_linux.8214685.zip
          21 kB
        8. jdk-14+8_linux.8214685.zip
          20 kB
        9. jdk-15+14_linux.8214685.zip
          21 kB
        10. jdk-15+19_linux.8214685.zip
          21 kB
        11. jdk-15+33_linux.8214685.zip
          22 kB

          Issue Links



              Unassigned Unassigned
              dcubed Daniel Daugherty
              0 Vote for this issue
              4 Start watching this issue