RFR(S): 8228625: [TESTBUG] sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr

[Alex Menkov]

You can use jdk.test.lib classes to simplify the things.
Something like

ProcessBuilder pb = new 
ProcessBuilder(JDKToolFinder.getTestJDKTool("jshell"));
Process p = ProcessTools.startProcess("JShell", pb,
     s -> {  // warm-up predicate
         return s.contains(">jshell");
     });

--alex

On 09/18/2019 15:44, Chris Plummer wrote:
> Is there an easy way of doing this? Currently the jshell process is just 
> spawned using Runtime.exec().
> 
> Chris
> 
> On 9/18/19 3:01 PM, Alex Menkov wrote:
>> Hi Chris,
>>
>> Did you think about waiting for jshell prompt ("jshell>") before run 
>> "jhsdb jmap" command instead of delay or re-tries?
>>
>> --alex
>>
>> On 09/18/2019 14:11, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following changes:
>>>
>>> http://cr.openjdk.java.net/~cjplummer/8228625/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8228625
>>>
>>> There are actually numerous ways that JShellHeapDumpTest.java fails. 
>>> One is a test bug, being addressed here, and the rest all seem to be 
>>> SA bugs. Those are now being covered by JDK-8230872. All the issues 
>>> seem to stem from the fact that the test spawns a jshell process, and 
>>> then immediately does a "jhsdb jmap" on the process before jshell has 
>>> fully started up.
>>>
>>> The test bug happens when the jmap succeeds, but jshell has not yet 
>>> entered the main java thread. Thus the search for 
>>> "JShellToolProvider" in the output fails. It expects 
>>> "JShellToolProvider" to be in the output because it is part of a 
>>> method name in the main thread, and the test dump all the thread 
>>> stacks contained in the jmap generated hprof file. When the test 
>>> fails in this way, you can see the stack dump in the output, but the 
>>> main thread is missing.
>>>
>>> There's a couple of ways to fix this. One is to just add a delay (10s 
>>> seems to be more than enough), and the other is to retry the "jhsdb 
>>> jmap" command until the stack contains the JShellToolProvider symbol. 
>>> I chose the later because doing a 10s delay masks the SA issues that 
>>> are now covered by JDK-8230872. In a way the 10s delay is a better 
>>> fix, because it makes this test pass every time, but I did not like 
>>> that it also hid real SA problems in JDK-8230872. My plan for now is 
>>> to do this retry fix, and then if there are too many failures due to 
>>> JDK-8230872, then also add a 10s delay, with the intention of 
>>> removing it once JDK-8230872 if fixed. From what I can see, 
>>> JDK-8230872 failures happen on about 1% of the runs.
>>>
>>> I made a few of other changes. One was to no longer redirect stderr 
>>> from the jmap process as was done from the following:
>>>
>>> processBuilder.redirectError(ProcessBuilder.Redirect.INHERIT);
>>>
>>> This causes the output not to appear in the OutputAnalyzer output, 
>>> resulting in the following not working:
>>>
>>>              output.shouldNotContain("null");
>>>
>>> Also I added code to dump the output of the jshell process so you can 
>>> see if the jshell prompt was ever generated.
>>>
>>> thanks,
>>>
>>> Chris
>>>
> 
>