Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CDFA6C7.1070304@zeus.net.au>
Date: Sun, 14 Nov 2010 19:07:19 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Debugging River (Was: Re: new release?)
References: <4CDD1D83.2030600@qcg.nl> <4CDD1ECC.6050902@zeus.net.au>
 <4CDD4D48.2050901@acm.org> <4CDDB7F8.2010309@zeus.net.au>
 <4CDDD6B7.70109@acm.org> <4CDDDB01.8080901@zeus.net.au>
 <4CDE0D28.4080502@acm.org> <4CDE5067.2070905@zeus.net.au>
 <4CDEAC1B.40009@acm.org> <4CDFA5A0.4090201@zeus.net.au>
In-Reply-To: <4CDFA5A0.4090201@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Firmstone wrote:
> Patricia Shanahan wrote:
>> On 11/13/2010 12:46 AM, Peter Firmstone wrote:
>>> Patricia Shanahan wrote:
>>>> On 11/12/2010 4:25 PM, Peter Firmstone wrote:
>>>>> Patricia Shanahan wrote:
>>>>>> On 11/12/2010 1:56 PM, Peter Firmstone wrote:
>>>>>>> Patricia Shanahan wrote:
>>>>>>>> Peter Firmstone wrote:
>>>>>>>>> Sim IJskes - QCG wrote:
>>>>>>>>>> Now that we have the QA testing working, a very important step,
>>>>>>>>>> should we go for a release?
>>>>>>>>>>
>>>>>>>>>> My personal feelings are: It is really a big step, which 
>>>>>>>>>> merits a
>>>>>>>>>> release on its own.
>>>>>>>>>>
>>>>>>>>>> Gr. Sim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Yes definitely soon, there are still two failing qa and one jtreg
>>>>>>>>> test I'd like to look at, if I get some time over the weekend, 
>>>>>>>>> I'll
>>>>>>>>> investigate setting up the KDC also, then we should release.
>>>>>>>>
>>>>>>>> Would you like me to look at one of the failing tests? I can't
>>>>>>>> promise
>>>>>>>> anything because I have a lot of non-Apache commitments over the
>>>>>>>> weekend.
>>>>>>>>
>>>>>>>> Patricia
>>>>>>>>
>>>>>>>>
>>>>>>> Yes please ;)
>>>>>>>
>>>>>>> The failling tests are:
>>>>>>>
>>>>>>> 1. Jtreg: qa/jtreg/net/jini/url/httpmd/TestEqual.java
>>>>>>> 2. QA: com/sun/jini/test/impl/start/ServiceStarterCreateBad
>>>>>>> TransientServiceTest.td
>>>>>>> 3. QA: com/sun/jini/test/impl/start/ServiceStarterCreateSha
>>>>>>> redBadActServiceTest.td
>>>>>>>
>>>>>>> Note the QA tests pass with JDK 1.5 but fail with JDK 1.6
>>>>>>>
>>>>>>> Build is compiled with 1.6.
>>>>>> ...
>>>>>>
>>>>>> I can't reproduce the QA failures. I compiled and ran with JDK
>>>>>> 1.6.0_22, and with no differences between my working River and the
>>>>>> trunk head. Any ideas on how to get them to happen?
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>>
>>>>> I ran against JDK 1.6.0_07, I'll try a later version, perhaps the QA
>>>>> tests are caused by JDK bugs, need to identify the bug if this is the
>>>>> case.
>>>>
>>>> They pass with JDK 1.6.0_07. I think there must be some difference
>>>> other than JDK version that matters here.
>>>>
>>>> Patricia
>>>>
>>> Thank you, has anyone tried using a debugger with the qa tests? I think
>>> I need to step though this one.
>>
>> I've used Eclipse to debug the test itself - not the services it is 
>> using. The instructions in http://www.screaming-penguin.com/node/7353 
>> were helpful. Essentially, you set testjvmargs in 
>> qaDefaults.properties for debug through a specific socket, and then 
>> set up an external debug configuration in Eclipse to use the same 
>> socket. The most difficult part was finding out how to escape a comma 
>> in testjvmargs, and I've added a comment about that.
>>
>> Before a debug session, I rebuild with debug enabled in the compile 
>> parameters, so that I can view local variables etc., and check that 
>> the problem sill happens. If not, I just have to live without local 
>> variables.
>>
>> I assume the principles would be the same for any debugger with 
>> external process debug capability.
>>
>> However, using a debugger has serious limitations. In particular, 
>> River is not the sort of thing you can just step through. Once you 
>> stop and look at a breakpoint, a lot will have changed and the run 
>> often won't take the same path, because of timeouts and relative 
>> order changes. It reminds me a bit of debugging operating systems. On 
>> the other hand, restarting and hooking up the debugger is much faster 
>> than rebuilding.
>>
>> My main technique for debugging River is to add calls to 
>> System.err.println (or printf) and rebuild. I know, it is not 
>> sophisticated or elegant, but it works.
>>
>> At the end of a debug session, I revert all changes. If I found a 
>> fix, I copy the fix into a clean check-out before reverting. Also, I 
>> use a tag, "XXXpats", in each printout. That makes it easy to find 
>> them in the output, and to check that I've got rid of all the calls 
>> in the source code.
>>
>> I've repeated the 1.6.0_07 runs 670 times overnight, without a single 
>> failure, so I don't see much chance of being able to reproduce it 
>> here without additional insight.
>>
>> For most of this weekend, I'll either be out or sleeping, but I will 
>> try to keep an eye on my e-mail on an iPhone, and respond if I have 
>> something short and useful to say.
>>
>> Happy bug hunting!
>>
>> Patricia
>>
> Thanks Patricia,
>
> Well, remember how you discovered the + escape character?  Well 
> running jdb isn't too hard for a test, you just append the following 
> to the *.td test description file:
>
> testjvmargs=-Xdebug,\
> -Xrunjdwp:transport=dt_socket+,address=8000+,server=y+,suspend=y,\
> ${testjvmargs}
>
> Execute ant run-tests (set run-tests="path to test description file" 
> in build.properties, then from another terminal window run:
>
> jdb -attach 8000
>
> I'm currently stepping through with jdb after setting a break point in 
> MarshalledObject.get, unfortunately there are no debugging symbols in 
> JDK 1.6's URLStreamHandler, so I can't see the methods I'm most 
> interested in.
>
> This could take a little while.
>
> Cheers,
>
> Peter.
>

I have a hunch it's got something to do with the policy being replaced 
with bogus policy in the test, this could have something to do with the 
way that JDK 1.6 loads the security policy, if the security manager 
isn't loaded at start up, optimisation can reorder the calls so the 
policy is late loaded.

But I could be wrong.

Cheers,

Peter.