sh files in ProblemList (was Re: Need reviewers - jdk testing changes 6888927)

[Kelly O'Hair]

Jonathan Gibbons wrote:
> Kelly O'Hair wrote:
>> I just now am fixing some demo/jvmti tests, which seemed to fail
>> with samevm and pass with othervm, the problem seemed to be that
>> when run with samevm, the current directory (user.dir) is different.
> 
> The current directory should always be the scratch/ subdirectory of the 
> work directory, so by default, it should be JTwork/scratch.   Any other 
> behavior is a bug that I would be interested to know about (and fix.)
> 

The demo/jvmti tests build up a command line and exec it with Java code,
it never set the classpath before, and the classname was just put on
the java command line, assuming the current directory was the same
directory as where the classfile was. My fix was to add a -cp arg
with the test.classes directory.
So I'm just assuming the user.dir was different between -samevm and not.

The demo/jvmti tests are NOT shell tests.

-kto

>>
>> So if a test is assuming anything about the current directory, that
>> could be an issue. But again, I didn't think that the shell tests
>> would be impacted even by this, since they would be run with othervm.
> 
> Yes, shell tests are always run othervm. You should be able to assume 
> the current directory is empty when the test starts, and is available 
> for writing in.
> 
>>
>> The samevm feature was pretty dusty before Jon started getting it
>> working again, so there may be misc minor issues involved with it.
> 
> I don't think there's an "again" there -- it was always pretty dusty! 
> Following Kelly's lead to provide simplified automated support for run 
> as many tests as fast as possible, I'm open to suggestions to improve 
> samevm mode. There's one big issue on record about the security manager; 
> the next biggest issue is around being able to accept VM options for 
> running tests in sameVM mode.
> 
>>
>> But I think your shell tests may have been just problematic when multiple
>> instances of them are run on one machine, like a port number problem.
>> That's hard for me to diagnose quickly, so when tests failed with
>> any kind of BindException or 'address already in use', I just added
>> them to the list and moved on.
>>
>> -kto
>>
>> Max (Weijun) Wang wrote:
>>> Hi Kelly
>>>
>>> I'm looking at the ProblemList.txt file, which contains some .sh 
>>> files in my area. I guess the .sh files should behave the same no 
>>> matter if -savevm is turned on, since it's always launched in another 
>>> process. Am I right?
>>>
>>> These tests (except one) normally pass when I run them (even on JPRT 
>>> on all platforms). Can you show me how they fail on your system? say, 
>>> a list of jtr files I can look into?
>>>
>>> Thanks
>>> Max
>>>
>>> On Nov 7, 2009, at 6:57 AM, Kelly O'Hair wrote:
>>>
>>>> Tim,
>>>>
>>>> I was going to push these test changes into the jdk7/build forest,
>>>> but maybe it makes more sense to push it into the jdk7/tl forest?
>>>> Any opinions on that?
>>>>
>>>> Fresh webrev:
>>>>  6888927: Fix jdk jtreg tests to indicate which ones need othervm, 
>>>> allow for use of samevm option
>>>>  http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/ 
>>>>
>>>>
>>>> I've run it maybe a dozen times now and the test list is starting
>>>> to stabilize.
>>>>
>>>> After I push it, I planned on working on fixing some of the
>>>> serviceability tests and get them off the ProblemList.
>>>> And that definitely seemed like a jdk7/tl change.
>>>>
>>>> ---
>>>>
>>>> All,
>>>>
>>>> Let me know who wants to be listed as a reviewer on this changeset.
>>>>
>>>> -kto
>>>
>