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

[Chris Plummer]

Ok. It was a bit unclear to me why the author went with Runtime.exec() 
in the first place. I'll try ProcessTools. That will probably however, 
hide 8230872. I might need to write another test for it.

Chris

On 9/18/19 4:29 PM, Alex Menkov wrote:
> 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
>>>>
>>
>>