harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Date Fri, 17 Nov 2006 17:49:11 GMT
Elena Semukhina wrote:
> On 11/17/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>
>> Elena Semukhina wrote:
>> > On 11/16/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> >>
>> >> Elena Semukhina wrote:
>> >> > As Gregory mentioned ThreadTest.testJoinlongint() failure he 
>> observed
>> >> > yesterday, I filed a
>> http://issues.apache.org/jira/browse/HARMONY-2204
>> >> > issue
>> >> > for that. I saw this failure quite long ago but cannot reproduce it
>> >> today
>> >> > trying different platforms/EMs. When the test failed, it reported
>> that
>> >> > actual wait time is less than required.
>> >> >
>> >> > The spec for join() reads: "Waits at most millis milliseconds plus
>> >> > nanosnanoseconds for this thread to die. " There is an obvious
>> >> > misprint here:
>> >> > there should be "at least" but not "at most" and this was mentioned
>> in
>> >> >
>> >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
>> >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
>> >> >
>> >> > On the other hand, in classlib ThreadTest I saw that they agree with
>> >> > Thread.sleep(1000)  duration >= 800 and join(100, 999999) 
>> duration <=
>> >> 300.
>> >> >
>> >> > Can the current DRLVM guarantee that it does not exit join() earlier
>> >> than
>> >> > expected?
>> >> > If not, we should make the test more tolerable to timing.
>> >>
>> >> There is also an unstable ObjectTest.testWaitlongint which fails once
>> in
>> >> a while (about once in 50 - 100 runs). It also seems to wait a bit 
>> less
>> >> than required. I think there is also a bug in the test, nanos 
>> should be
>> >> 500000, not 500. But fixing this doesn't help, test still fails on
>> >> windows.
>> >
>> >
>> > Gregory, why do you think this is a bug? nanos can be any value between
>> 0
>> > and 999999. Actually there is a bug in thread_native_condvar.c which
>>
>> Yes it can. But I think that comparison at the end of the test that
>> "finish - start + 1 > millis" mean that it should be 1 more millisecond
>> of waiting. To do this it was intended to wait for 500 and a half =
>> 500.5 milliseconds, which means that nanos should be 500000, not 500.
>>
>> Correct my if I am wrong about the original test intension.
> 
> 
> I'm not an author of the test but I think we should wait one more
> millisecond even if we ask to wait 500.0005 ms because a millisecond is a
> minimal available time unit. I expect that the time is rounded up rather
> than towards the nearest vlaue. Am I wrong?

Well it appears that on windows assertion in the test fails once in a 
while. The time of waiting finish - start + 1 = 500, so it is not 
strictly greater than millis = 500.

I didn't try to run the test multiple times after your patch to APR. 
I'll let you know if I get the failures again.

-- 
Gregory


Mime
View raw message