Bug ID: JDK-8231297 java/lang/ProcessBuilder/Basic.java test fails intermittently

JDK 18
18Resolved

There have been no sightings of this since JDK-8272600 was fixed. Fixed by: Changeset: 0a361638 Author: Roger Riggs <rriggs@openjdk.org> Date: 2021-09-22 13:55:19 +0000 URL: https://git.openjdk.java.net/jdk/commit/0a361638c5ea4d3e109d950e34a61b4737c8f670
09-11-2021
Yes, using a native executable adds complexity to a test, and some of that complexity burden is pushed to the one running the test, so it's best to avoid when possible. When all you need is a native executable that can sleep, it's tempting to query the ambient OS to see whether it provides one. If a "sleep" program is available, it probably does what we want. If we try and fail to run "sleep", we can skip to the next subtest.
25-08-2021
It might have been simpler to reduce background VM activity with Epsilon GC, and running with the interpreter only (-Xint).
25-08-2021
PR to switch to a native test program to do the sleeping: https://github.com/openjdk/jdk/pull/5239
24-08-2021
Output from hotspot interfering with the intended output from a program has long been a problem, and not only in testing. It's one of the reasons java has not been popular for writing e.g. Unix filter programs. The usual local solution is to ensure output-suppressing hotspot flags are passed to java, but of course that is not always possible. I agree with [~iklam] that using a simple native program as a subprocess is less errorprone due to avoidance of threading and unwanted hotspot output. When this test was written there was no support for building native programs for use by tests - hence the popularity of using a java subprocess.
23-08-2021
> What is the reliable way to determine if the VM is quiesced? The VM is never fully quiesced. The closest you would get would be to run a simple program, possibly in interpreter mode, with SerialGC, have the program write something to stdout/err you can check for as a signal to do the destroy, and then do a long Thread.sleep.
17-08-2021
If the test needs to run a subprocess that doesn't write to stdout/stderr under any circumstances, it shouldn't use a complex program such as the Java. I think it would be much easier to spawn a dedicated native program. Native test programs are supported by the build system already. E.g., see test/jdk/native_sanity/simplenativelauncher/ProgramTest.java, where the native program is built as ./images/test/jdk/jtreg/native/sanity_SimpleNativeLauncher
17-08-2021
True, that output may come from other sources, though output from other sources has not been seen. But it is quite reasonable to be able to control and direct all of the output from the VM. Waiting for the VM to complete initialization is possible but time based delays are unreliable. The wait time before destroying the subprocess has already been extended (and could be again). Even if a more elaborate mechanism can be created to wait until the child is 'ready', the VM is doing other activities asynchronously (including creating threads) and it might still be the case that the same failure to create a thread could happen when the child is destroyed and still produce unexpected output to stdout. So that's not a 100% solution either. What is the reliable way to determine if the VM is quiesced?
16-08-2021
IIUC there is also no guarantee that the VM is destroyed after it has processed the flags that are redirecting output to stderr.
16-08-2021
The test kills a subprocess abruptly during VM start-up. We cannot guarantee that the VM will print no output under this scenario (caused by the apparent idiosyncrasies of Windows process termination). Many users will benefits from HotSpot's diagnostic output when VM bootstrap fails unexpectedly. If this test turns out to be a requirement that "HotSpot must provide an option to not print any messages when killed abruptly", then this becomes not a corelib test but a HotSpot test. However, we have no such requirement. The fact that this would be convenient for a single test in corelib is not a strong reason to have such a requirement. It's even possible that such messages may come from a lower level, outside the control of HotSpot. For example, it's possible for one thread to be killed in the middle of a malloc, leaving a corrupted heap, but another thread manages to run a little longer to attempt to malloc, causing the malloc library to print an error message reporting the heap corruption. In general, I don't think you can assume that Process.destroy() will not print anything to stdout/stderr.
16-08-2021
The purpose of the test is to verify that the buffering in the test program correctly works as intended, in particular, blocking with no input and then producing EOF as specified when the child is destroyed. There should be no input from the child, as it would keep the input stream from blocking. It seemed reasonable that the child could be and was programmed to produce no output.
16-08-2021
> [0.036s][warning][os,thread] Failed to start thread "Unknown thread" ... The fact this prints "Unknown thread" indicates it is a JavaThread that was being started, but the lack of a following warning from JVM_StartThread: "Failed to start the native thread for java.lang.Thread \"%s\" suggests this was a compiler thread that could not be started. The failure modes of this test makes no sense to me. We see: ----------System.err:(21/1085)---------- Error occurred during initialization of VM >'-1'< not equal to '91' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1377) but the "Error occurred during initialization of VM" is not related to the subsequent text. If the VM fails during initialization then it aborts. I also note that if the JavaThread that we could not create was one of the internal VM threads, then it would cause the "Error occurred during initialization of VM" but it would also say: "java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached" that said any time the VM exits during termination we will see a more detailed message. So perhaps it is as [~iklam] suggested above that the external call to destroy the process first triggers the error that causes thread creation to fail and we then continue a little way reporting that failure before the process actually is destroyed.
16-08-2021
Also note from the test: // The debug/fastdebug versions of the VM may write some warnings to stdout // (i.e. "Warning: Cannot open log file: hotspot.log" if the VM is started // in a directory without write permissions). These warnings will confuse tests // which match the entire output of the child process so better filter them out. return output.replaceAll("Warning:.*\\n", ""); but that filtering looks to me like the pre-Unified-Logging format of a VM warning, so this has actually been failing to filter out VM warnings since Java 9. Perhaps we just need to reinstate an accurate filter for VM warnings?
16-08-2021
Interestingly the same kinds of failures can be seen in GHA: STDERR: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by Basic (file:/D:/a/jdk17/jdk17/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/java/lang/ProcessBuilder/Basic_id0.d/) WARNING: Please consider reporting this to the maintainers of Basic WARNING: System::setSecurityManager will be removed in a future release Warning: warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. Error occurred during initialization of VM java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached at java.lang.Thread.start0(java.base/Native Method) at java.lang.Thread.start(java.base/Thread.java:802) at java.lang.ref.Finalizer.<clinit>(java.base/Finalizer.java:189) >'-1'< not equal to '10' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1380) at Basic.fail(Basic.java:2803) at Basic.fail(Basic.java:2804) at Basic.equal(Basic.java:2810) at Basic$12.run(Basic.java:2202) java.lang.AssertionError: Some tests failed but this time the output makes a little more sense. The failure to start the finalizer thread still hints at the problem [~iklam] suggested. I think there is basic flaw in thinking that when you call destroy on a process can you can reasonably infer anything about how the process will behave as it is terminated. Paging [~martin] as the original author of this test. :)
16-08-2021
I've filed JDK-8272121 for the stdout bug.
09-08-2021
> Can anyone explain how the logging of "_beginthreadex failed"... was output to stdout instead of stderr as requested by the "-Xlog..." command line args? Something seems broken with UL: $ /d/ade/apps/Java/jdk-17/bin/java -Xlog:all=warning:stderr -Xloggc:gc.log -version > stdout.txt 2> stderr.txt $ cat stdout.txt [0.004s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead. $ cat stderr.txt [0.004s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead. java version "17-internal" 2021-09-14 LTS Java(TM) SE Runtime Environment (build 17-internal+0-LTS-2021-05-26-2325074.david.holmes.jdk-dev2.git) Java HotSpot(TM) 64-Bit Server VM (build 17-internal+0-LTS-2021-05-26-2325074.david.holmes.jdk-dev2.git, mixed mode, sharing) The warning went to stdout and stderr! I've confirmed that somehow all warnings go to stdout and also to whereever warnings have been redirected!
09-08-2021
> It appears that -Xlog output is not redirected by the flags "-XX:+DisplayVMOutputToStderr" and -XX:+DisplayVMOutputToStdout. Correct - those flags just control the behaviour of the VM tty output stream. -Xlog output is controlled by the -Xlog options.
14-04-2021
It appears that -Xlog output is not redirected by the flags "-XX:+DisplayVMOutputToStderr" and -XX:+DisplayVMOutputToStdout. The "Error occurred during initialization of VM" was redirected as expected, but the beginthreadx message is using logging.
13-04-2021
Here's a snippet from the log file for the jdk-17+18-1444-tier8 sighting: #section:main ----------messages:(5/340)---------- command: main -Djdk.lang.Process.launchMechanism=fork Basic reason: User specified action: run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic Mode: othervm [/othervm specified] Additional options from @modules: --add-modules java.base --add-opens java.base/java.lang=ALL-UNNAMED elapsed time (seconds): 83.598 ----------configuration:(4/99)---------- Boot Layer add modules: java.base add opens: java.base/java.lang ALL-UNNAMED ----------System.out:(36/1776)---------- This appears to be a Windows system. This appears to be a Unicode-based OS. Testing ASCII environment values Testing Latin1 environment values Testing directory . Testing directory .. Testing directory \\ Testing directory C: Testing directory c: Testing directory C:\\ Testing directory c:\\ Testing directory \\ Testing directory c:\\windows Testing directory c:\\Program Files Testing directory c:\\Program Files Testing Unicode directory:.\\ProcessBuilderDir?? Running case insensitve variable tests cmdp cmdp 0: c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-17+18-1444\\windows-x64-debug.jdk\\jdk-17\\fastdebug\\bin\\java cmdp 1: -XX:+DisplayVMOutputToStderr cmdp 2: -classpath cmdp 3: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\5\\java\\lang\\ProcessBuilder\\Basic_id0.d;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-17+18-1444\\src.full\\open\\test\\jdk\\java\\lang\\ProcessBuilder;T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\5\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-17+18-1444\\src.full\\open\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\javatest.jar;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\jtreg.jar cmdp 4: Basic$JavaChild cmdp 5: System.getenv() envp envp 0: SystemRoot=C:\\Windows envp 1: LC_ALL=C\u0000\u0000 envp 2: FO\u0000=B\u0000R Unexpected child output: [0.089s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. END Child output. waitFor process: delta: 12750260 Passed = 9675, failed = 1 ----------System.err:(21/1085)---------- Error occurred during initialization of VM >'-1'< not equal to '91' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1377) at Basic.fail(Basic.java:2796) at Basic.fail(Basic.java:2797) at Basic.equal(Basic.java:2803) at Basic$12.run(Basic.java:2196) java.lang.AssertionError: Some tests failed at Basic.main(Basic.java:2808) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed ----------rerun:(56/6020)----------
13-04-2021
The fix in https://bugs.openjdk.java.net/browse/JDK-8263729 may address this issue. Leaving this open to see if the fix is effective.
22-03-2021
It's unlikely that _beginthreadex failed due to lack of memory. We are running on a machine with more than 50GB ram with only concurrency of 6. Extracts from the logs: $ jtreg -vmoption:-Xmx512m -concurrency:6 -vmoption:-XX:MaxRAMPercentage=4 .... open/test/jdk:jdk_lang start = Wed Mar 10 22:54:53 GMT 2021 end = Wed Mar 10 22:56:36 GMT 2021 elapsed= 102932 0:01:42.932 ---------------------------------------- [2021-03-10 22:57:07] [C:\cygwin\bin\free.exe] timeout=20000 ---------------------------------------- total used free shared buff/cache available Mem: 50068964 19974888 30094076 0 0 30094076 Swap: 8388608 105048 8283560 ---------------------------------------- [2021-03-10 22:57:07] exit code: 0 time: 33 ms ----------------------------------------
17-03-2021
The point of the test is to verify the exception that occurs when the process is destroyed with no output pending. The test does wait (but only 10ms) after it detects that the thread waiting on the read is in the correct state. Extending the time from 10ms to 100ms or larger would give the child more time to settle. Its main thread is sleeping so any activity is in non-Java threads. I will propose a patch. https://github.com/openjdk/jdk/pull/3049
17-03-2021
Hmm, the output "[warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES)" may actually be expected: The test case starts a child JVM process and almost immediately kills it. During the child's bootstrap, several Java threads would be created. At the time the parent process calls Process.destroy, which in turn calls the Windows TerminateProcess API, the child process may not have finished bootstrapping, so it may still be trying to create threads. The Windows API doc is unclear about what happens when one process calls TerminateProcess on another process. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminateprocess "When a process terminates itself, TerminateProcess stops execution of the calling thread and does not return. Otherwise, TerminateProcess is asynchronous; it initiates termination and returns immediately. " It's unclear whether code in the child process can still continue execution after "termination is initiated". See discussion here: https://stackoverflow.com/questions/40427263/is-waiting-needed-after-terminateprocessgetcurrentprocess-exit-code From the test log, the "termination" may have made it impossible to launch any new threads, but existing threads somehow still get to run a little longer before they are forcibly killed. ================================ The purpose of the test case is not "early VM bootstrap termination". Rather, it is: //---------------------------------------------------------------- // Check that reads which are pending when Process.destroy is // called, get EOF, or IOException("Stream closed"). //---------------------------------------------------------------- Maybe it shouldn't try to kill the child process so early? This may be the cause of earlier failures as well (when "access denied" was given during file operations). I would suggest changing the test to: wait for the child process to print a line like "I have started" to STDERR, then start the main logic of this test on STDOUT. And vice versa.
16-03-2021
That's good advice, but the system has to work well even if its not done and I don't think its contributing to the problem in this case. Though there is some question about why starting the VM thread by the fails. Only this one subtest has failed with these symptoms and there numerous other tests executed.
16-03-2021
I would recommend rewriting the test to enforce more discipline in freeing the resources of the child processes, in a way that's similar to the test library method jdk.test.lib.process.ProcessTools.executeProcess, which has been used all over the test cases and have been proven robust. Something like: try { TestProcess tp = makeTestProcess(javaChildArgs); } { final Process p = tp.getProcess(); // the original test code as in my last comment } class TestProcess implements java.io.Closeable { public void close() { // drain the stdout/stderr // waitfor // call destroyForcibly if necessary // see jdk.test.lib.process.ProcessTools.executeProcess() } }
16-03-2021
Does this test properly clean up resources for each of it child processes? I see that it uses Process.destroy(), but the javadoc says: public abstract void destroy() Kills the subprocess. Whether the subprocess represented by this Process object is forcibly terminated or not is implementation dependent. For example, in this case, the test code just calls p.destroy() without doing any of these: - wait for the child process to exit - drain the stdout/stderr of the child process //---------------------------------------------------------------- // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS) // interrupt works as expected, if interrupted while waiting. //---------------------------------------------------------------- try { List<String> childArgs = new ArrayList<String>(javaChildArgs); childArgs.add("sleep"); final Process p = new ProcessBuilder(childArgs).start(); final long start = System.nanoTime(); final CountDownLatch aboutToWaitFor = new CountDownLatch(1); final Thread thread = new Thread() { public void run() { try { aboutToWaitFor.countDown(); Thread.currentThread().interrupt(); boolean result = p.waitFor(30L * 1000L, TimeUnit.MILLISECONDS); fail("waitFor() wasn't interrupted, its return value was: " + result); } catch (InterruptedException success) { } catch (Throwable t) { unexpected(t); } } }; thread.start(); aboutToWaitFor.await(); thread.interrupt(); thread.join(10L * 1000L); check(millisElapsedSince(start) < 10L * 1000L); check(!thread.isAlive()); p.destroy(); } catch (Throwable t) { unexpected(t); }
16-03-2021
That particular test, is launching hundreds of processes (I don't know the exact count). It tests many combinations of arguments, returns, streams, signaling, etc. The particular subtest is verifying how streams are buffered and closed when a process is destroyed. The output reported was generated in a child process that had been sent a destroy signal very soon after it was started. Possibly before all threads in the child had been started, especially VM threads (not Java Threads).
16-03-2021
According to MS documentation https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-160 ======== Return Value On an error, _beginthread returns -1L, and errno is set to EAGAIN if there are too many threads, to EINVAL if the argument is invalid or the stack size is incorrect, or to EACCES if there are insufficient resources (such as memory). ======== All the recently reported failures are showing EACCES. Maybe our tier6/8 configs have caused too much load on the system? But it's also strange because in the very last reported tier8 failure (mach5-one-jdk-17+13-959-tier8-20210309-0313-18942298), all 869 tests passed except for java/lang/ProcessBuilder/Basic.java. Maybe there's something special about this test that causes it to fail more likely in such situations?
16-03-2021
ILW = MLM = P4
16-03-2021
Please re-triage and assign this. It continues to occur and needs a hotspot evaluation. See comments above. https://bugs.openjdk.java.net/browse/JDK-8231297?focusedCommentId=14398931&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14398931
11-03-2021
The subset of test cases in java/lang/Basic that are failing intermittently, is creating processes, getting them into a known state waiting for I/O and then destroying them by calling the Windows API, terminateProcess(handle, 1). The test driver is reading the output of the child process and produces the output: [0.128s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. That message is from hotspot code attempting to create a new thread. os/windows/os_windows.cpp line: 770 A possible diagnostic would be to force a core dump or stack trace. The state of each of the threads in the process is unknown nor the timing of this message and process termination.
04-02-2021
Can someone help interpret the output from the child process? It appears to be logging info from the vm: " [0.128s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. "
27-01-2021
Here's a snippet from the log file for the jdk-16+27-1807-tier6 failure: #section:main ----------messages:(5/340)---------- command: main -Djdk.lang.Process.launchMechanism=fork Basic reason: User specified action: run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic Mode: othervm [/othervm specified] Additional options from @modules: --add-modules java.base --add-opens java.base/java.lang=ALL-UNNAMED elapsed time (seconds): 88.782 ----------configuration:(4/99)---------- Boot Layer add modules: java.base add opens: java.base/java.lang ALL-UNNAMED ----------System.out:(36/1776)---------- This appears to be a Windows system. This appears to be a Unicode-based OS. Testing ASCII environment values Testing Latin1 environment values Testing directory . Testing directory .. Testing directory \\ Testing directory C: Testing directory c: Testing directory C:\\ Testing directory c:\\ Testing directory \\ Testing directory c:\\windows Testing directory c:\\Program Files Testing directory c:\\Program Files Testing Unicode directory:.\\ProcessBuilderDir?? Running case insensitve variable tests cmdp cmdp 0: c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+27-1807\\windows-x64-debug.jdk\\jdk-16\\fastdebug\\bin\\java cmdp 1: -XX:+DisplayVMOutputToStderr cmdp 2: -classpath cmdp 3: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\6\\java\\lang\\ProcessBuilder\\Basic_id0.d;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+27-1807\\src.full\\open\\test\\jdk\\java\\lang\\ProcessBuilder;T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\6\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+27-1807\\src.full\\open\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\javatest.jar;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\jtreg.jar cmdp 4: Basic$JavaChild cmdp 5: System.getenv() envp envp 0: SystemRoot=C:\\Windows envp 1: LC_ALL=C\u0000\u0000 envp 2: FO\u0000=B\u0000R Unexpected child output: [0.128s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. END Child output. waitFor process: delta: 12638660 Passed = 9675, failed = 1 ----------System.err:(20/1041)---------- >'-1'< not equal to '91' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1377) at Basic.fail(Basic.java:2772) at Basic.fail(Basic.java:2773) at Basic.equal(Basic.java:2779) at Basic$12.run(Basic.java:2172) java.lang.AssertionError: Some tests failed at Basic.main(Basic.java:2784) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed ----------rerun:(55/5878)----------
01-12-2020
Here's a snippet from the log file for the jdk-16+25-1607-tier8 failure: ----------System.out:(36/1776)---------- This appears to be a Windows system. This appears to be a Unicode-based OS. Testing ASCII environment values Testing Latin1 environment values Testing directory . Testing directory .. Testing directory \\ Testing directory C: Testing directory c: Testing directory C:\\ Testing directory c:\\ Testing directory \\ Testing directory c:\\windows Testing directory c:\\Program Files Testing directory c:\\Program Files Testing Unicode directory:.\\ProcessBuilderDir?? Running case insensitve variable tests cmdp cmdp 0: c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+25-1607\\windows-x64-debug.jdk\\jdk-16\\fastdebug\\bin\\java cmdp 1: -XX:+DisplayVMOutputToStderr cmdp 2: -classpath cmdp 3: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\0\\java\\lang\\ProcessBuilder\\Basic_id0.d;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+25-1607\\src.full\\open\\test\\jdk\\java\\lang\\ProcessBuilder;T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\0\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+25-1607\\src.full\\open\\test\\lib;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\javatest.jar;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\jtreg.jar cmdp 4: Basic$JavaChild cmdp 5: System.getenv() envp envp 0: SystemRoot=C:\\Windows envp 1: LC_ALL=C\u0000\u0000 envp 2: FO\u0000=B\u0000R Unexpected child output: [0.123s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. END Child output. waitFor process: delta: 20967340 Passed = 9675, failed = 1 ----------System.err:(20/1041)---------- >'-1'< not equal to '91' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1377) at Basic.fail(Basic.java:2772) at Basic.fail(Basic.java:2773) at Basic.equal(Basic.java:2779) at Basic$12.run(Basic.java:2172) java.lang.AssertionError: Some tests failed at Basic.main(Basic.java:2784) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed ----------rerun:(56/5830)----------
19-11-2020
The unexpected output from the Child process bears investigating: "[0.181s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. "
26-08-2020
Here's a snippet from the log file for the jdk-16+13-503-tier8 failure: #section:main ----------messages:(5/340)---------- command: main -Djdk.lang.Process.launchMechanism=fork Basic reason: User specified action: run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic Mode: othervm [/othervm specified] Additional options from @modules: --add-modules java.base --add-opens java.base/java.lang=ALL-UNNAMED elapsed time (seconds): 90.068 ----------configuration:(4/99)---------- Boot Layer add modules: java.base add opens: java.base/java.lang ALL-UNNAMED ----------System.out:(36/1603)---------- This appears to be a Windows system. This appears to be a Unicode-based OS. Testing ASCII environment values Testing Latin1 environment values Testing directory . Testing directory .. Testing directory \\ Testing directory C: Testing directory c: Testing directory C:\\ Testing directory c:\\ Testing directory \\ Testing directory c:\\windows Testing directory c:\\Program Files Testing directory c:\\Program Files Testing Unicode directory:.\\ProcessBuilderDir?? Running case insensitve variable tests cmdp cmdp 0: c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+13-503\\windows-x64-debug.jdk\\jdk-16\\fastdebug\\bin\\java cmdp 1: -XX:+DisplayVMOutputToStderr cmdp 2: -classpath cmdp 3: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\1\\java\\lang\\ProcessBuilder\\Basic_id0.d;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+13-503\\src.full\\open\\test\\jdk\\java\\lang\\ProcessBuilder;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\javatest.jar;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\jtreg.jar cmdp 4: Basic$JavaChild cmdp 5: System.getenv() envp envp 0: SystemRoot=C:\\Windows envp 1: LC_ALL=C\u0000\u0000 envp 2: FO\u0000=B\u0000R Unexpected child output: [0.181s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. END Child output. waitFor process: delta: 15829880 Passed = 9675, failed = 1 ----------System.err:(20/1041)---------- >'-1'< not equal to '10' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1379) at Basic.fail(Basic.java:2731) at Basic.fail(Basic.java:2732) at Basic.equal(Basic.java:2738) at Basic$12.run(Basic.java:2131) java.lang.AssertionError: Some tests failed at Basic.main(Basic.java:2743) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed ----------rerun:(56/5389)----------
25-08-2020
Here's a snippet from the log file for the jdk-16+5-146-tier8 failure: ----------System.out:(36/1601)---------- This appears to be a Windows system. This appears to be a Unicode-based OS. Testing ASCII environment values Testing Latin1 environment values Testing directory . Testing directory .. Testing directory \\ Testing directory C: Testing directory c: Testing directory C:\\ Testing directory c:\\ Testing directory \\ Testing directory c:\\windows Testing directory c:\\Program Files Testing directory c:\\Program Files Testing Unicode directory:.\\ProcessBuilderDir?? Running case insensitve variable tests cmdp cmdp 0: c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+5-146\\windows-x64-debug.jdk\\jdk-16\\fastdebug\\bin\\java cmdp 1: -XX:+DisplayVMOutputToStderr cmdp 2: -classpath cmdp 3: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\classes\\7\\java\\lang\\ProcessBuilder\\Basic_id0.d;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-16+5-146\\src.full\\open\\test\\jdk\\java\\lang\\ProcessBuilder;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\javatest.jar;C:\\ade\\mesos\\work_dir\\jib-master\\install\\jtreg\\5.1\\b01\\bundles\\jtreg_bin-5.1.zip\\jtreg\\lib\\jtreg.jar cmdp 4: Basic$JavaChild cmdp 5: System.getenv() envp envp 0: SystemRoot=C:\\Windows envp 1: LC_ALL=C\u0000\u0000 envp 2: FO\u0000=B\u0000R Unexpected child output: [0.118s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. END Child output. waitFor process: delta: 53026120 Passed = 9675, failed = 1 ----------System.err:(20/1041)---------- >'-1'< not equal to '91' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1379) at Basic.fail(Basic.java:2731) at Basic.fail(Basic.java:2732) at Basic.equal(Basic.java:2738) at Basic$12.run(Basic.java:2131) java.lang.AssertionError: Some tests failed at Basic.main(Basic.java:2743) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed ----------rerun:(55/5324)----------
08-07-2020

Duplicate :	JDK-8272600 - (test) Use native "sleep" in Basic.java
Relates :	JDK-8272121 - Unified Logging always writes warnings to stdout

JDK-8232135 :	Add diagnostic output to test java/util/ProcessBuilder/Basic.java - Resolved
JDK-8261097 :	[test] Add diagnostic gathering to ProcessBuilder Basic test - Closed
JDK-8263696 :	Print more info when windows os::create_thread fails - Open
JDK-8263729 :	[test] divert spurious output away from stream under test in ProcessBuilder Basic test - Resolved
JDK-8265173 :	[test] divert spurious log output away from stream under test in ProcessBuilder Basic test - Resolved
JDK-8269929 :	(test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output - Resolved
JDK-8272600 :	(test) Use native "sleep" in Basic.java - Resolved