Fwd: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Aug 9 13:06:49 PDT 2011
Thanks for closing the loop. The changes are good as is.
On 8/9/11 2:02 PM, Chris Hegarty wrote:
> 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.
>>> -------- 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>
>>> 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.
>> 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
> 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.
>> Thumbs up.
More information about the serviceability-dev