Fwd: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) (original) (raw)

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Aug 9 09:11:16 PDT 2011


On 8/9/11 8:29 AM, Chris Hegarty wrote:

Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.

-Chris. -------- Original Message -------- Subject: Code Review 7073295: TESTBUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) Date: Tue, 09 Aug 2011 14:05:08 +0100 From: Chris Hegarty <chris.hegarty at oracle.com> To: core-libs-dev <core-libs-dev at openjdk.java.net>, "alan.bateman at oracle.com" <alan.bateman at oracle.com> Hi, This test creates temporary directories in the scratch area with spaces in their names. It fails on Cygwin because jtreg cannot cleanup after it. Easiest to just have the test cleanup (minimally) after itself. Webrev: http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/ Thanks, -Chris.

I run these tests all the time on WinXP/Cygwin so the use of the '-samevm' option is the enabler here also. 'samevm' mode is mentioned in this bug report (yeah!), but it could be more clear that the test falls over because that option is used.

Alan and I discussed this test off list and our last hypothesis was that the strange filenames/dirnames were the culprit. I just didn't get back to the issue. Sorry about that.

I'm not quite sure I have my brain wrapped around why ExampleForBootClassPath had to be added to the "@run build" line, but I'm OK with that change also.

I'm presuming that you are only cleaning up the hard to remove stuff and leaving the other dirs for JTREG to clean up. For example, there are two dirs: "has_leading_blank" and " has_leading_blank". The dir without the blank has the bad class file in it to make sure that we actually use the right dir (the one with the blank in it). Your fix only removes " has_leading_blank" and "has_leading_blank" is left behind.

The bug ID list should also be updated, but that's a nit.

Thumbs up.

Dan



More information about the serviceability-dev mailing list