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

[Alex Menkov]

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
>