On 11/28/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
Elena, It's nice to hear that you are making progress in running kernel tests iteratively. There is a parallel thread which discusses how we should integrate ability of iterative test runs into Harmony [1]. Both class library tests and kernel tests use <junit> ant task to run tests, so I cannot see a problem to create a common solution for both test suites. Could you please take a look and share your preference for one of three proposed approaches?
Alexei, I'm not an expert in ant for now so I cannot give a quick answer on my preferences unfortunately :( But I fully agree with you that iterative runs should be integrated into build system. I've written a shell script for iterative runs and someone mentioned in another thread that it is possible to execute such scripts in ant. Of course, another solution could be found, I hope. Thanks, Elena 1.
http://mail-archives.apache.org/mod_mbox/harmony-dev/200611.mbox/[EMAIL PROTECTED] -- Thank you, Alexei On 11/27/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > On 11/28/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > Elena, > > As far as I understand from your letter the implementation is still to > > be fixed. Could you please file a JIRA about it? > > > I'm not sure that the implementation is to be fixed as it does not > contradict the spec for now :) > Possibly we should fix the test so that it waits e.g. 10% less. Anyway, I've > filed http://issues.apache.org/jira/browse/HARMONY-2204 some time ago for > this problem. The patch I suggested is invalid because the test continues > failing with new timing numbers (I gave 1 ms of freedom but this was not > enough). > > Geir, > > As for the best of my knowledge there are no reliability runs for > > kernel tests. This case proves that trying to run these tests in a > > loop, especially in one JVM could be useful for detecting new > > implementation flaws. > > > It is me who runs these tests iteratively for the last week. The runs proved > that ThreadTest fails sporadically on waiting in join() and sleep() methods > on Windows and in yield() on linux. I'll file aJIRA issue for the latter. > > Thanks, > Elena > > -- > > Thank you, > > Alexei > > > > > > On 11/27/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > > On 11/28/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > > > > > > > The problem with ThreadTest has not been fixed yet. I'm running this > > test > > > > iteratively now to see the sporadic failures. Indeed, > > testJoinlongint() > > > > fails rather often. The spec for join() reads that it should wait at > > most > > > > millis milliseconds for this thread to die. But the thread which is > > > > joining in the test does not stop > > > > > > > > > > The obvious typo: I meant "the thread which is joined". > > > > > > > > > running. Can we allow join() to exit earlier in this case? > > > > > > > > > > I modified the test so that to let join() wait for10 ms less (which > > > is 0.5%of waiting time) and ran it again iteratively. It failed once > > > with 1972 ms > > > of waiting! > > > > > > I looked through RI's bug database for relevant issues and found the > > > following: > > > > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653 > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368 > > > > > > The last comment of the latter says that the spec will be fixed in Java > > SE > > > 6.0! > > > > > > BTW, the test always passes on linux for me. > > > > > > Thanks, > > > Elena > > > > > > > > > > On 11/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I may have missed it, it's very possible, could someone point me to > > the > > > > > fix > > > > > or the thread ? My comments are based on what's in Harmony drlvm > > trunk > > > > > as of > > > > > a few hours ago. > > > > > > > > > > Thanks, > > > > > Rana > > > > > > > > > > > > > > > On 11/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I thought this exact problem was identified and already fixed... > > > > > > > > > > > > geir > > > > > > > > > > > > Rana Dasgupta wrote: > > > > > > > Hi, > > > > > > > On Windows XP, java.lang.ThreadTest ( testJoinlongint > > component ) > > > > > > keeps > > > > > > > failing for me sporadically. Debugging this, I saw that the > > problem > > > > > was > > > > > > > with > > > > > > > the expiry interval on thread.join(millis, nanos ). Tests based > > on > > > > > timed > > > > > > > waits are somewhat unpredictable on most platforms. > > > > > > > In condvar_wait_impl(), we seem to set up the timeout interval > > in > > > > > > > microseconds before calling apr_thread_cond_timeout(). On > > Windows, > > > > > > > apr_thread_cond_timeout() implements using WaitForSingleObject( > > > > > event, > > > > > > > timeout )....but the Windows timeout is in milliseconds, as far > > as I > > > > > > > > > > > know. > > > > > > > Is this not an error, or am I missing something? I did not want > > to > > > > > > change > > > > > > > anything since condvar_wait_impl() is on the code path of > > several > > > > > timed > > > > > > > waits. > > > > > > > Also, on a less important note, the tests testJoinLong() and > > > > > > > testJoinLongint() seem to test to see that the thread.join > > (milli, > > > > > nano) > > > > > > > timeout is "at least" equal to the specified interval. My > > > > > understanding > > > > > > is > > > > > > > that this should be "at most" the specified interval. Any ideas? > > > > > > > > > > > > > > Thanks, > > > > > > > Rana > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Thanks, > > > > Elena > > > > > > > > > > > > > > > -- > > > Thanks, > > > Elena > > > > > > > > > > > > -- > > Thank you, > > Alexei > > > > > > -- > Thanks, > Elena > >
-- Thanks, Elena
