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)
    jdk/jfr/startupargs/TestStartDuration.java
    


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

jdk/jfr/startupargs/TestStartName.java

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: 

----------System.err:(24/1177)----------
 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]
----------rerun:(33/4073)*----------

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.)