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

[Chris Plummer]

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