RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test
Roger Riggs
rriggs at openjdk.java.net
Wed Mar 17 19:15:47 UTC 2021
On Wed, 17 Mar 2021 19:10:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> @tstuefe It's unlikely that _beginthreadex failed due to lack of memory. We are running on a machine with more than 50GB ram with only concurrency of 6. Extracts from the logs:
>>
>> $ jtreg -vmoption:-Xmx512m -concurrency:6 -vmoption:-XX:MaxRAMPercentage=4 .... open/test/jdk:jdk_lang
>>
>> start = Wed Mar 10 22:54:53 GMT 2021
>> end = Wed Mar 10 22:56:36 GMT 2021
>> elapsed= 102932 0:01:42.932
>>
>> ----------------------------------------
>> [2021-03-10 22:57:07] [C:\cygwin\bin\free.exe] timeout=20000
>> ----------------------------------------
>> total used free shared buff/cache available
>> Mem: 50068964 19974888 30094076 0 0 30094076
>> Swap: 8388608 105048 8283560
>> ----------------------------------------
>> [2021-03-10 22:57:07] exit code: 0 time: 33 ms
>> ----------------------------------------
>>
>> My theory is that `TerminateProcess` has made it impossible for the child process to spawn new threads, but somehow existing threads are still able to run a little bit and produce the log message.
>>
>> Of course this is just a theory, and I cannot find any supporting docs from MS. However, if we implement the work around and make sure we don't kill the child until it has finished bootstrapping, and the bug doesn't happen anymore, then we know something more.
>
> Hmm. That's strange.
>
> One issue I don't understand with this test, should the parent not read from both streams simultaneously, because if the child is sending output to the stream the parent is not reading from the child may block on write?
>
> This depends on file io buffer size of course but if the child writes some larger output into e.g. stderr while the parent reads stdout, parent will wait on stdout and child will wait on the write to stderr finishing. So, either we should read both streams or redirect the stream we are not interested in to paren'ts stdout/stderr where hopefully the testrunner itself would read it.
>
> I may misunderstand the test completely; if yes, sorry for the confusion!
>
> Thomas
The child does no (zero) writes to either stream. It is invoked only to sleep until it is destroyed.
The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).
-------------
PR: https://git.openjdk.java.net/jdk/pull/3049
More information about the core-libs-dev
mailing list