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 14:53:38 GMT
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.

> ignores
> any nanos < 1000 when converting them to microseconds.
> 
> The spec for Object.wait(long) reads that waiting lasts until:
> ...
> The specified amount of real time has elapsed, more or less.
> 
> It does not say neither "at most" nor "at least". I think we can fix both
> tests so that they could wait a little bit less than it is now expected and
> print the values at error messages. I attached a patch to HARMONY-2204.
> Please take a look and commit if it is OK. Then we can see if the tests
> still fail.

-- 
Gregory


Mime
View raw message