[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Need reviewer - jdi tests fixes
From:       Daniel.Daugherty () Sun ! COM (Daniel D !  Daugherty)
Date:       2009-11-25 18:27:44
Message-ID: 4B0D7720.1080704 () sun ! com
[Download RAW message or body]

Kelly O'Hair wrote:
>
> Daniel D. Daugherty wrote:
>> Kelly O'Hair wrote:
>>> Need reviewer on changes to the com/sun/jdi tests.
>>>
>>> 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm
>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-test-changes/webrev/

<snip>

>> test/com/sun/jdi/BadHandshakeTest.java
>>    This alternate architecture stuff is screaming for a
>>    refactoring. Can you file a new bug to document that
>>    we need to do that?
>
> Ok. Will do. I'll make it P4, not sure when anyone will have time
> for it.  Filed 6904593.

Thanks for filing the bug. I moved it to
java/java/debugger.


>
>> test/com/sun/jdi/RepStep.java
>>    You might want to add a comment about why this has
>>    to be an "othervm" test.
>
> I honestly am not sure, after making the basic changes for
> classpath, I could not figure out why this test was problematic,
> adding othervm made it pass. Some of these tests are not
> horribly straight forward, or my mind has turned to mush because
> I can't figure some of them out at times. :^(
> So any comment I could add would be less that trustworthy,
> and it doesn't seem to be worth a great deal of time to figure
> out why.
>
> I've seen many tests like this, pass with othervm, don't
> with samevm, if it's not obvious, I just mark it othervm.
> Or if I suspect this test is polluting the state of the 'samevm'
> and making other tests fail, I'll just mark it othervm.

I only meant for you to add a comment if you already
knew the reason why. I didn't want you to burn any
cycles trying to figure out why.


>
>> test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java
>>    Did the original test really have an empty string as
>>    part of the command?
>
> Yes it did. :^(  Looks like it glued the classname to the
> address, I don't understand how this ever worked.

I just checked the 2009.11.24 nightly results for
RT_Baseline and this test wasn't run by this name.
The test has this comment:


24 /*
25 * A Simple LaunchingConnector used by unit test :-
26 * test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java
27 */

Nightly doesn't keep the .jtr files for tests that
have passed so I checked my JDK7-B76 baseline results.
My DebugUsingCustomConnector.jtr file shows that the
SimpleLaunchingConnector.java was compiled as part of
the test run. The test run shows no errors, but there is
also no obvious indication that the SimpleLaunchingConnector
class was used at all. So without diving into the test base
itself, I don't have any good answers about this piece of
test code :-)

Dan


[prev in list] [next in list] [prev in thread] [next in thread]