TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Tue Aug 9 09:25:55 PDT 2011

On 08/ 9/11 05:18 PM, Jim Holmlund wrote:

Will this work on older versions of cygwin? Or do we have a spec someplace that says cygwin versions older than xxxx aren't supported?

I have not seen any docs/spec anywhere for support of /dev/null in specific Cygwin releases, but I did test on 1.5 and 1.7.9 and MKS, and all went fine.

http://www.cygwin.com/cygwin-ug-net/using-specialnames.html

I didn't have time to submit a jprt job on this, but tested on Windows Cygwin/MKS, Solaris, and Linux. I believe the TL integrator will be doing a full jprt run later today. If we don't see a few hundred failures then we should be good ;-)

-Chris.

- jjh

On 8/9/2011 8:56 AM, Chris Hegarty wrote: Sorry Dan, I'll put a more complete description in the bug report.

This issue, from what I can tell only happens with very recent Cygwin versions. I'm running 1.7.9. When running the com/sun/jdi tests in a batch, in samevm mode, this test leave behind a file, NUL, in the scratch directory that cannot be deleted. This causes the remaining tests to also fail. Thanks for the review, -Chris. On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote: On 8/9/11 8:52 AM, Chris Hegarty wrote: Hi Dan, Alan,

This is a trivial change to use /dev/null instead of NUL for Windows test with Cygwin. http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/ Thanks, -Chris. I'm good with the change, but the bug report itself is less than clear. I run these tests all the time on WinXP/Cygwin so I'm guessing that there is more going on here than meets the eye. I'm going to guess that the '-samevm' option is the enabler for this failure mode. The failure mode that you fixed should also affect tests other than BreakpointWithFullGC.sh so I'm not quite sure why this issue appears with just that test. Or maybe it does appear with other tests, but again the bug report isn't clear. In any case, thumbs up on the change. Dan

More information about the serviceability-dev mailing list