JDK-8024660 : TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 7,8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2013-09-12
  • Updated: 2013-12-16
  • Resolved: 2013-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b115Fixed
Related Reports
Relates :  
JDK-7147084 - (process) appA hangs when read output stream of appB which starts appC that runs forever
Description
2 tests fail on fastdebug builds in HotSpot compiler nightly:
  java/lang/ProcessBuilder/InheritIOEHandle.java
  java/lang/ProcessBuilder/SiblingIOEHandle.java

because JTreg fails to cleanup after tests writing: StatusError: failed to clean up files after test...

JTreg tries to remove hotspot.log file generated by test's processes, but fails because one of them is still holding the hotspot.log file.
This file is generated by default on fatsdebug VM builds.

Both tests synchronize processes A and C with the file StopC.txt. Process C waits in a loop for a StopC.txt file created in the test directory, and if file exists process C exits. StopC.txt file is created by process A after A is done its work.
When A ends JTreg marks test as passed and tries to remove all files in test directory ("-retain:none"). Because C checks for a file with some timeout  JTreg is able to remove StopC.txt file and hence C will end much later holding the hotspot.log file for a while.
JTreg can't remove the hotspot.log file while it's open by C.

To fix this test process A should wait for C and exit only after C is finished.
Comments
Review request: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021673.html
04-10-2013
I am familiar with hotspot.log and it's good to hear that you've got a good handle on the issue. Rob is going to take the issue and hopefully we can get this test fixed in 8 soon.
12-09-2013
@Alan, hotspot.log is a log file generated by fastdebug VM. It could be also generated if VM option -XX:+LogVMOutput specified. VM keeps this file open while process is running, and then closes it. This is a normal behavior for the HotSpot VM. The issue is that process C ends later than process A, and hence jtreg begin to cleanup test directory with StopC.txt file before process C sees it. Patch I have attached works as expected without errors form the jtreg on spbef02.ru.oracle.com.
12-09-2013
Alan, I've turned off McAfee and rerun tests again, and they still fail. It's not an issue with AV. Test don't fail if they are ran using jtreg with "-retain:all". But after run process C is still running until it hits timeout. So I think that an issue is in the test itself. Process A exits too early. Instead it should wait for C. In all runs jtreg 4.1 fcs b06 was used. Is there a newer version of jtreg?
12-09-2013
@Pavel - it is possible to repeat this on a system that has McAfee disabled? We've been have annoying issues like this with the AV software interfering with test runs on Windows systems. It would also be interesting to see if running with the latest jtreg will help as there are changes in jtreg nightly that help with the cleanup.
12-09-2013
Suggested fix: Add wait for process C finish before we pass a test. Also done a little cleanup and re-factoring.
12-09-2013