river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Debugging River (Was: Re: new release?)
Date Sun, 14 Nov 2010 11:32:51 GMT
Peter Firmstone wrote:
> 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
>>>>>>>>>> weekend, I'll
>>>>>>>>>> investigate setting up the KDC also, then we should
>>>>>>>>> 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
>>>>>>> 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
>>>>>> 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.
> Don't panic there are debugging symbols, don't know what happened there!
>> This could take a little while.
>> Cheers,
>> Peter.

Well the good news is that with debugging turned on, the test still 
fails, so it's solvable, the bad news is, I haven't worked out why yet 
and I'm not going to have much time over the next week.  Will let you 
know how I go.



View raw message