On Wed, 17 Mar 2021 19:10:24 GMT, Thomas Stuefe <stu...@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

Reply via email to