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

[Chris Hegarty]

On 08/ 9/11 05:11 PM, Daniel D. Daugherty wrote:
> 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: TEST_BUG:
>> 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.

Sorry my fault, most of our recent test issues have been caused by 
samevm mode, it's hard to think of anything else now ;-(

> 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.

The reason for adding ExampleForBootClassPath to the build line is that 
the shell script at some point moves ExampleForBootClassPath.class to a 
different dir.  If the test is rerun without removing 
ManifestTestApp.class, then jtreg does not recompile 
ManifestTestApp.java, which means that ExampleForBootClassPath doesn't 
get compiled, which means the .class file is not in the expected dir. 
(Thanks JimH for finding this.)

Not a showstopper, but worth fixing since we noticed it.

> 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.

That's right, not exactly pretty but I though it was the simplest way to 
go here. jtreg can handle the rest.

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

Ahhh... sorry. Probably not worth filing a CR to add this, but I will 
piggyback it to my next changeset if that is ok.

-Chris.

> Thumbs up.
>
> Dan
>
>
>