RFR: JDK-8154326: bash >(...) construct causes race conditions
tim.bell at oracle.com
Thu Apr 21 14:11:34 UTC 2016
> Unfortunately, this did not work well. The problem with the added "&&
> wait" materializes if the caller of ExecuteWithLog tries to pipe the
> output of that command, which we do frequently on Windows. To solve
> it, another level of parentheses are needed. Unfortunately this adds
> another shell process for each call, which makes the Windows build
> slightly slower again. I don't see any other solution however.
> Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.02/
OK, looks good to me.
> On 2016-04-19 14:32, Erik Joelsson wrote:
>> After switching to the new hotspot build, we have seen some sporadic
>> build errors related to the generation of dtrace JvmOffsets.h file on
>> Solaris. The errors look like a compile target that depends on the
>> header file fails because the header file is either empty or
>> incomplete. I have managed to reproduce this by running this
>> particular part of the build in a loop within 5 minutes.
>> The header file generation uses the rather new ExecuteWithLog macro,
>> which uses the also rather new ">(tee logfile)" construct to save
>> output to a log file while still echoing both stderr and stdout
>> separately to the console. It seems however, that when using this
>> construct, bash spawns background processes which may not be done
>> when the main process is done.
>> I have noted a similar effect when switching to this construct for
>> the main makefile build.log. The last line of make output would be
>> echoed to the console after my prompt returned.
>> To solve this, I added "&& wait" in each location where the >(...)
>> trick is used. I have then rerun the loop over night and could no
>> longer reproduce the problem. I believe this to be the proper solution.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154326
>> Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.01/
More information about the build-dev