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

[Alex Menkov]

Oh, I mean

s.contains("jshell>")

--alex

On 09/18/2019 16:29, 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
>>>>
>>
>>