Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

On 11/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> 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, 99) 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
>> 50, 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 99. 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 50, 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?


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





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> 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, 99) 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
50, 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 99. Actually there is a bug in thread_native_condvar.c which 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.

I checked the APR function and underlying win API functions, the

System.currentTimeMillis is measured with microseconds accuracy. The
Thread.join and Thread.wait end up with WaitForSingleObject function
which accepts an argument in milliseconds. So I cannot understand why
the wait/join time is less than required.

--
Gregory





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

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, 99) 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.

On 11/16/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


Thank you, Gregory!

On 11/15/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> Elena Semukhina wrote:
> > I've found one more issue in the kernel ThreadTest. Filed
> > https://issues.apache.org/jira/browse/HARMONY-2193.
> >
> > Alexey, please take a look!
>
> I am not an Alexey, but I assigned this JIRA to myself. The testcase
> seems to be working both on linux and windows, I committed the patch.
>
> > On 11/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> >>
> >> 2006/11/14, Gregory Shimansky < [EMAIL PROTECTED]>:
> >> > On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> >> > > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED] > wrote:
> >> > > > After H-1823 has been committed, I still see intermittent
> failures
> >> of
> >> > > > drlvm kernel ThreadTest. Normally this test passes but today I
> got
> >> > > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked()
> >> failures.
> >> > > > There is H-1789 for the first issue but it is not reprodiced
> with
> >> the
> >> > > > attached test anymore. For the second test I filed H-1876 to
> make
> >> the
> >> > > > test more stable. The patch has been committed recently but the
> >> test
> >> > > > still may fail. I'd like someone to review the above mentioned
> >> tests
> >> to
> >> > > > be sure they are correct otherwise we need to investigate
> failures
> >> and
> >> > > > file JIRA's before the tests are exclued.
> >> > >
> >> > > I looked at ThreadTest again and found one more incorrectness in
> >> > > testGetStateBlocked(): it does not wait for the thread's run()
> method
> >> > > actually starts. I filed
> >> https://issues.apache.org/jira/browse/HARMONY-2166
> >> > > and attached the patch. I ran the test more than 100 times and
> did
> >> not
> >> see
> >> > > a failure.
> >> >
> >> > Cool! I'd like to see this patch applied (in case it really helps)
> >> ASAP.
> >> > Alexey V, please don't hold it for long. I would really like to see
> all
> >> > acceptance to pass again on all platforms and then we'll maintain
> no
> >> > regression state.
> >>
> >> Verified and applied (at r474672). BTW, seems we are very close to
> >> 100% pass rate for classlib tests on DRLVM. The wiki status page [1]
> >> lists just few pending issues, hopefully we'll fix them all in a
> >> couple of days.
> >>
> >> [1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
> >>
> >
> >
> >
>
>
> --
> Gregory
>
>


--
Thanks,
Elena





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

Thank you, Gregory!

On 11/15/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> I've found one more issue in the kernel ThreadTest. Filed
> https://issues.apache.org/jira/browse/HARMONY-2193.
>
> Alexey, please take a look!

I am not an Alexey, but I assigned this JIRA to myself. The testcase
seems to be working both on linux and windows, I committed the patch.

> On 11/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>>
>> 2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
>> > On Monday 13 November 2006 15:51 Elena Semukhina wrote:
>> > > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> > > > After H-1823 has been committed, I still see intermittent
failures
>> of
>> > > > drlvm kernel ThreadTest. Normally this test passes but today I
got
>> > > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked()
>> failures.
>> > > > There is H-1789 for the first issue but it is not reprodiced with
>> the
>> > > > attached test anymore. For the second test I filed H-1876 to make
>> the
>> > > > test more stable. The patch has been committed recently but the
>> test
>> > > > still may fail. I'd like someone to review the above mentioned
>> tests
>> to
>> > > > be sure they are correct otherwise we need to investigate
failures
>> and
>> > > > file JIRA's before the tests are exclued.
>> > >
>> > > I looked at ThreadTest again and found one more incorrectness in
>> > > testGetStateBlocked(): it does not wait for the thread's run()
method
>> > > actually starts. I filed
>> https://issues.apache.org/jira/browse/HARMONY-2166
>> > > and attached the patch. I ran the test more than 100 times and did
>> not
>> see
>> > > a failure.
>> >
>> > Cool! I'd like to see this patch applied (in case it really helps)
>> ASAP.
>> > Alexey V, please don't hold it for long. I would really like to see
all
>> > acceptance to pass again on all platforms and then we'll maintain no
>> > regression state.
>>
>> Verified and applied (at r474672). BTW, seems we are very close to
>> 100% pass rate for classlib tests on DRLVM. The wiki status page [1]
>> lists just few pending issues, hopefully we'll fix them all in a
>> couple of days.
>>
>> [1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
>>
>
>
>


--
Gregory





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

I've found one more issue in the kernel ThreadTest. Filed
https://issues.apache.org/jira/browse/HARMONY-2193.

Alexey, please take a look!

On 11/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:


2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
> On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > > After H-1823 has been committed, I still see intermittent failures
of
> > > drlvm kernel ThreadTest. Normally this test passes but today I got
> > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked()
failures.
> > > There is H-1789 for the first issue but it is not reprodiced with
the
> > > attached test anymore. For the second test I filed H-1876 to make
the
> > > test more stable. The patch has been committed recently but the test
> > > still may fail. I'd like someone to review the above mentioned tests
to
> > > be sure they are correct otherwise we need to investigate failures
and
> > > file JIRA's before the tests are exclued.
> >
> > I looked at ThreadTest again and found one more incorrectness in
> > testGetStateBlocked(): it does not wait for the thread's run() method
> > actually starts. I filed
https://issues.apache.org/jira/browse/HARMONY-2166
> > and attached the patch. I ran the test more than 100 times and did not
see
> > a failure.
>
> Cool! I'd like to see this patch applied (in case it really helps) ASAP.
> Alexey V, please don't hold it for long. I would really like to see all
> acceptance to pass again on all platforms and then we'll maintain no
> regression state.

Verified and applied (at r474672). BTW, seems we are very close to
100% pass rate for classlib tests on DRLVM. The wiki status page [1]
lists just few pending issues, hopefully we'll fix them all in a
couple of days.

[1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM





--
Thanks,
Elena

Re: Please set a "Patch available" flag for H-1669 Was: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Elena Semukhina]

On 11/14/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:


Elena,

Could you please set "Patch available" flag for the following issue to
attract committer's attention to this issue?
http://issues.apache.org/jira/browse/HARMONY-1669 Classlib test
tests/api/java/io/PipedInputStreamTest hangs on Windows 2003

(After the last JIRA configuration changes a submitter can edit her
issues).



Done!

With best regards,

Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Elena Semukhina [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 3:56 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> My 2003 server is installed on a single core P4 with HT. The test
>attached
>> to HARMONY-1669 works fine for me both with and without patch :)
>>
>> I may get an access to dual core server as described in JIRA but I am
>> afraid
>> it will take a few days. Probably we can just apply the patch since
it
>> doesn't seem to do any harm.
>
>
>Indeed the attached test passes and PipedInputStream test passes being
run
>separately now but when I ran the whole luni module, it hung. I applied
the
>patch and it helped.
>
>2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>> >
>> >
>> >
>> > Rana Dasgupta wrote:
>> > > On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >> So since I don't have Win 2003, I gotta just commit and let
someone
>> > else
>> > >> test?
>> > >>
>> > >> Any committer have win 2003?
>> > >
>> > >
>> > > I think that it may be hard to find a test at this point that
fails
>on
>> > > Windows Server 2003, but passes on XP. But perf etc.
characteristics
>> > > will be
>> > > different. At some point, gc_v5 etc. is likely to have server
>specific
>> > > variations, eg., parallel gc may be on server only.
>> > >
>> > > Are we talking of tests in general? I am sorry, but I may not
have
>> > > understood the comment.
>> >
>> > There is a test that demonstrates a Win 2003 bug...  I can just
commit
>> > it and let someone confirm since I don't have a win 2003 machine
>> >
>> > geir
>> >
>>
>>
>> --
>> Gregory Shimansky, Intel Middleware Products Division
>>
>>
>
>
>--
>Thanks,
>Elena





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


After H-1823 has been committed, I still see intermittent failures of
drlvm kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first issue but it is not reprodiced with the
attached test anymore. For the second test I filed H-1876 to make the test
more stable. The patch has been committed recently but the test still may
fail. I'd like someone to review the above mentioned tests to be sure they
are correct otherwise we need to investigate failures and file JIRA's before
the tests are exclued.



I looked at ThreadTest again and found one more incorrectness in
testGetStateBlocked(): it does not wait for the thread's run() method
actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 and
attached the patch. I ran the test more than 100 times and did not see a
failure.



Vera, could you please review the tests?


 On 10/26/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>
> +1 to exclude failing tests for now and require that all remaining tests
> must pass. Assuming some tests fail anyway cause people don't treat the
> failures seriously. As soon as the bug causing the failure is fixed the
> tests need to be unexcluded.
>
> Thanks,
> Pavel
>
>
> On 10/26/06, Rana Dasgupta <[EMAIL PROTECTED] > wrote:
> >
> > The ideal way would be for acceptance tests like "build test" to
> always
> > pass
> > and to catch and roll back the patch that breaks this invariant,
> rather
> > than
> > to disable the tests. But I agree with Vera, it is important to keep a
> > running set up as acceptance tests, so disabling the well known
> failures
> > may
> > be the only way until we fix the problems.
> >
> > I don't know that any of the tests are "unstable". These are
> > implementation
> > bugs. gc.LOS is a bug in thread yielding by the apr Windows
> functionality.
> > The java.lang.ObjectTest also looks like an interpreter implementation
> > error.
> >
> >
> >
> >
> >
> > > On 10/25/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Geir
> > > > Some tests launched by command "build test" fail.
> > > > The idea of  "build test" is to run it before each commit. In this
> way
> > > > you can catch regressions.
> > > > In order to effectively catch regressions, i.e. tests that started
> to
> > > > fail after some change,
> > > > it's necessary to have 'build test' pass in a stable way. One of
> the
> > > > ways to achieve stable state
> > > > is to exclude failing tests or tests which show unstable behavior.
> > > > So I analysed statistics of test runs on win ia32 platform and
> made up
> > a
> > > > list of tests to be excluded:
> > > > 1) smoke
> > > > *** gc.LOS fails always on jitrino and interpreter, debug and
> release
> > > > 2) kernel
> > > > *** java.lang.ClasssGenericsTest and
> > > > *** java.lang.ClassGenericsTest4 fail because of timeout, so
> > I  increase
> > > > timeout in kernel.test.xml
> > > > *** java.lang.ObjectTest fail on interpreter with following
> message:
> > > > Testsuite: java.lang.ObjectTest
> > > > Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec
> > > > Testcase: testWait1(java.lang.ObjectTest): FAILED
> > > > An InterruptedException must be thrown in test thread!
> > > >junit.framework.AssertionFailedError: An InterruptedException
> must
> > be
> > > > thrown in test thread!
> > > >
> > > > See HARNONY-1966 issue with attached patch.
> > > >
> > > >
> > > > Vera Volynets
> > > > Intel Middleware ProductsDivision
> > > >
> > >
> > >
> >
> >
>
>


--
Thanks,
Elena





--
Thanks,
Elena

Re: [classlib][nio] SocketChannelTest fails on Windows 2003 server

[Elena Semukhina]

On 10/27/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:


On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I ran classlib tests on Windows 2003 server and saw the
> org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test
> failure. I've reported this at
> https://issues.apache.org/jira/browse/HARMONY-1977.


Hi Elena, does this test always fail on windows 2003 server?

Can RI pass this test?



Andrew,
the test fails on RI too.

iirc, there're some other tests in nio are platform dependent. We're waiting

for TestNG. :) These tests are marked with "FIXME".  If the test you found
is also platform-dependent, maybe mark it with "FXIME" and comment the
assert is a simple workaround now. :) Thanks!




We are talking about testSocket_NonBlock_ActionsBeforeConnect() test. It
uses special assertion method assertSocketAction_NonBlock_BeforeConnect()
which, in turn, contains a few assertions and is called not from this test
only but from another test as well. And that test passes this assertion. I'm
not sure that I know which is better: to commented out the whole assertion
in the test or a particular assertion in the assert method :(



Could anyone look at the issue?
>
> --
> Thanks,
> Elena
>
>


--
Best regards,
Andrew Zhang





--
Thanks,
Elena

[classlib][nio] SocketChannelTest fails on Windows 2003 server

[Elena Semukhina]

Hello,

I ran classlib tests on Windows 2003 server and saw the
org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test
failure. I've reported this at
https://issues.apache.org/jira/browse/HARMONY-1977.

Could anyone look at the issue?

--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> After H-1823 has been committed, I still see intermittent failures of
drlvm
> kernel ThreadTest. Normally this test passes but today I got
> ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
> There is H-1789 for the first issue but it is not reprodiced with the
> attached test anymore. For the second test I filed H-1876 to make the
test
> more stable. The patch has been committed recently but the test still
may
> fail. I'd like someone to review the above mentioned tests to be sure
they
> are correct otherwise we need to investigate failures and file JIRA's
> before
> the tests are exclued.

For me ThreadTest (testJoinlongint) always fails on win32 2003 server
SP1 on P4 with HT, works ok on win32 XP and on different Linuxes. I just
checked and patch from 1876 is applied, but it fixes another test case,
so it is not relevant.

BTW I've encountered timeout on ClassGenericsTest and ClassGenericsTest4
tests on some slower machines, so it looks like they do require
increased timeout. Now I agree completely with patch which Vera attached
in HARMONY-1966.



I don't agree that we should exclude the whole ObjectTest (or ThreadTest).
They contain dozens of test cases and if we have one test case stably or
intermittently failing we should file JIRA first and then comment out this
test case so that other test cases could run. In JIRA comment we need to
note that the test was commented out and uncomment it at the same time when
JIRA is fixed.

--

Gregory Shimansky, Intel Middleware Products Division





--
Thanks,
Elena

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Elena Semukhina]

After H-1823 has been committed, I still see intermittent failures of drlvm
kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first issue but it is not reprodiced with the
attached test anymore. For the second test I filed H-1876 to make the test
more stable. The patch has been committed recently but the test still may
fail. I'd like someone to review the above mentioned tests to be sure they
are correct otherwise we need to investigate failures and file JIRA's before
the tests are exclued.

Vera, could you please review the tests?


On 10/26/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:


+1 to exclude failing tests for now and require that all remaining tests
must pass. Assuming some tests fail anyway cause people don't treat the
failures seriously. As soon as the bug causing the failure is fixed the
tests need to be unexcluded.

Thanks,
Pavel


On 10/26/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> The ideal way would be for acceptance tests like "build test" to always
> pass
> and to catch and roll back the patch that breaks this invariant, rather
> than
> to disable the tests. But I agree with Vera, it is important to keep a
> running set up as acceptance tests, so disabling the well known failures
> may
> be the only way until we fix the problems.
>
> I don't know that any of the tests are "unstable". These are
> implementation
> bugs. gc.LOS is a bug in thread yielding by the apr Windows
functionality.
> The java.lang.ObjectTest also looks like an interpreter implementation
> error.
>
>
>
>
>
> > On 10/25/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
> > >
> > > Geir
> > > Some tests launched by command "build test" fail.
> > > The idea of  "build test" is to run it before each commit. In this
way
> > > you can catch regressions.
> > > In order to effectively catch regressions, i.e. tests that started
to
> > > fail after some change,
> > > it's necessary to have 'build test' pass in a stable way. One of the
> > > ways to achieve stable state
> > > is to exclude failing tests or tests which show unstable behavior.
> > > So I analysed statistics of test runs on win ia32 platform and made
up
> a
> > > list of tests to be excluded:
> > > 1) smoke
> > > *** gc.LOS fails always on jitrino and interpreter, debug and
release
> > > 2) kernel
> > > *** java.lang.ClasssGenericsTest and
> > > *** java.lang.ClassGenericsTest4 fail because of timeout, so
> I  increase
> > > timeout in kernel.test.xml
> > > *** java.lang.ObjectTest fail on interpreter with following message:
> > > Testsuite: java.lang.ObjectTest
> > > Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec
> > > Testcase: testWait1(java.lang.ObjectTest): FAILED
> > > An InterruptedException must be thrown in test thread!
> > >junit.framework.AssertionFailedError: An InterruptedException
must
> be
> > > thrown in test thread!
> > >
> > > See HARNONY-1966 issue with attached patch.
> > >
> > >
> > > Vera Volynets
> > > Intel Middleware ProductsDivision
> > >
> >
> >
>
>





--
Thanks,
Elena

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

On 10/26/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:


If this is a bug, have you logged an issue with Eclipse? If not,
please do so and post the bug URL here, so we can monitor it. You may
want to try compiling this with the latest ECJ JAR (3.3 nightly) to
see if it's still generating the same bytecode.



Nathan, here is the bug URL:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356
I tried ecj.jar 3.3 and still was able to reproduce the bug.

Considering that the RI can run this code fine, I'd be surprised if

this is considered a bug. I've been surprised before though. :)



The test I submitted to Eclipse bugzilla fails on RI, IBM VM and DRLVM when
compiled with ECJ and passes being compiled with javac.

The fix submitted to H-1931 takes this bug into account and relies on the
private modifier of a local class which is provided by Eclipse compiler (but
not provided by javac). So the accessibility control algorithm takes
different branches for the classes compiled with javac and ECJ for now.




-Nathan

On 10/25/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Is this a fix or a workaround?  Is there a bug in ECJ?
> >
> > geir
>
>
> Me and Evgueni consider this a fix.
> We should adapt the algorithm of accessibility control to working with
> classes compiled with both compilers. The difference berween compilers
is
> that javac does not provide any modifiers to local classes while ECJ
makes
> them private. On the other hand, javac provides some data for local
classes
> while ECJ does not  (and here is a bug in ECJ).
> The algorithm of checking accessibility has been modified so that it
does
> not fully rely on the data provided by compiler for local classes but
makes
> an additional check of local class modifiers to ensure proper
accessibility
> control for local classes.
>
>
>
> Elena Semukhina wrote:
> > > I attached the patch to H-1931 which fixes algorithm of checking
> > > accessibility. Please review!
> > >
> > > On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
> > >>
> > >> I think getEnclosingClass returns null not because of the "strange"
> > >> name but because it doesn't generate the enclosing method attribute
> > >> for local classes.
> > >>
> > >> Evgueni
> > >>
> > >> On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > >> > On Tuesday 24 October 2006 05:12 Nathan Beyer wrote:
> > >> > > By "inner class" you mean an automatic/local class in this
case; a
> > >> > > class declared inside a method. It would seem appropriate that
a
> > >> local
> > >> > > class is declared private. Only the method that contains the
class
> > >> > > declaration can see it.
> > >> > >
> > >> > > Do you disagree with what ECJ is generating?
> > >> >
> > >> > After reading this thread I think you are right and it is ok to
> > >> generate
> > >> > private attribute for inner classes.
> > >> >
> > >> > There is another difference between compilers output. Sun
compiler
> > and
> > >> ECJ
> > >> > generate different class names for Test1931_2.java inner class.
Sun
> > >> compiler
> > >> > creates Test1931_2$1LocalClass.class while ECJ creates
> > >> > Test1931_2$1$LocalClass.class.
> > >> >
> > >> > It might be not the cause of the bug in this case, but I wonder
> > whether
> > >> naming
> > >> > of inner classes is specified somewhere. Shouldn't names be the
same
> > >> for
> > >> all
> > >> > compilers?
> > >> >
> > >> > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > >> > > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
> > >> > > > > I haven't had a chance to look at the issue (JIRAs down
right
> > >> now,
> > >> > > > > probably part of the infrastructure move), but have you
tried
> > >> > > > > comparing the actual class files of the problematic class
or
> > >> classes.
> > >> > > > >
> > >> > > > > I'd suggest compiling the files using ECJ, save them off,
> > compile
> > >> with
> > >> > > > > Sun/BEA/etc, save them off and then run javap from a single
> > >> JDK on
>

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Is this a fix or a workaround?  Is there a bug in ECJ?

geir



Me and Evgueni consider this a fix.
We should adapt the algorithm of accessibility control to working with
classes compiled with both compilers. The difference berween compilers is
that javac does not provide any modifiers to local classes while ECJ makes
them private. On the other hand, javac provides some data for local classes
while ECJ does not  (and here is a bug in ECJ).
The algorithm of checking accessibility has been modified so that it does
not fully rely on the data provided by compiler for local classes but makes
an additional check of local class modifiers to ensure proper accessibility
control for local classes.



Elena Semukhina wrote:

> I attached the patch to H-1931 which fixes algorithm of checking
> accessibility. Please review!
>
> On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
>>
>> I think getEnclosingClass returns null not because of the "strange"
>> name but because it doesn't generate the enclosing method attribute
>> for local classes.
>>
>> Evgueni
>>
>> On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > On Tuesday 24 October 2006 05:12 Nathan Beyer wrote:
>> > > By "inner class" you mean an automatic/local class in this case; a
>> > > class declared inside a method. It would seem appropriate that a
>> local
>> > > class is declared private. Only the method that contains the class
>> > > declaration can see it.
>> > >
>> > > Do you disagree with what ECJ is generating?
>> >
>> > After reading this thread I think you are right and it is ok to
>> generate
>> > private attribute for inner classes.
>> >
>> > There is another difference between compilers output. Sun compiler
and
>> ECJ
>> > generate different class names for Test1931_2.java inner class. Sun
>> compiler
>> > creates Test1931_2$1LocalClass.class while ECJ creates
>> > Test1931_2$1$LocalClass.class.
>> >
>> > It might be not the cause of the bug in this case, but I wonder
whether
>> naming
>> > of inner classes is specified somewhere. Shouldn't names be the same
>> for
>> all
>> > compilers?
>> >
>> > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
>> > > > > I haven't had a chance to look at the issue (JIRAs down right
>> now,
>> > > > > probably part of the infrastructure move), but have you tried
>> > > > > comparing the actual class files of the problematic class or
>> classes.
>> > > > >
>> > > > > I'd suggest compiling the files using ECJ, save them off,
compile
>> with
>> > > > > Sun/BEA/etc, save them off and then run javap from a single
>> JDK on
>> > > > > each of the class files and compare them for differences.
>> > > >
>> > > > Yes, it is quite interesting how different compilers produce
>> different
>> > > > class attributes, it looks like this is the main problem with the
>> code.
>> > > > ECJ insists on marking inner classes private. Elena was kind to
>> send
>> me
>> > > > another test which she wrote while JIRA was down and it shows
>> even a
>> > > > bigger difference between the compilers - it produces different
>> output on
>> > > > RI. In the 2nd test ECJ creates an inner in anonymous class
>> > > > Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass.
>> This
>> > > > gives different output from cc.getEnclosingClass and
>> cc.isLocalClass
>> > > > where cc is the used inner class.
>> > > >
>> > > > Nevertheless RI allows the access to the inner private class it
>> seems. It
>> > > > doesn't throw the exception which drlvm does. The exception
source
>> is
>> > > > drlvm's kernel class ReflectExporter and the method in question
is
>> > > > allowAccess which calls allowClassAccess at line 113. This check
is
>> the
>> > > > one and the only chance to return true in this case.
>> > > >
>> > > > I've debugged the code with recently implemented debugging
support
>> of
>> > > > drlvm using eclipse (jdwp agent has to be build for this from
>> > > > HARMONY-1410, also kernel classes for drlvm aren't compiled with
>> debug
>> > > > support, build script has to be hacked) but I just don't know
>> all of
>> the
>> > > > access checks specification statements to make a decision which
one
>> is
>> > > > not correct.
>> > > >
>> > > > P.S. I used ecj 3.2 which we use for current classlib
compilation.
>> >
>> > --
>> > Gregory Shimansky, Intel Middleware Products Division
>> >
>>
>
>
>





--
Thanks,
Elena

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Ok - I committed the change to DRLVM, but asked that you take the change
to the classlib unit test and create a new JIRA so it's less confusing,
because the fix to to the unit test wasn't related to the setMaxPrio bug



HARMONY-1955 has been created reporting classlib ThreadGroupTest failures on
drlvm.

geir



Elena Semukhina wrote:
>
> On 10/24/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Just to be clear - does J9 exhibit the same problem as the RI?
>
>
> Yes, it does. The test passes on J9.
>
>
> Elena Semukhina wrote:
>  > I attached two new patches to HARMONY-1625 which fix the test and
> copy RI
>  > bug to drlvm ThreadGroup implementation :(
>  > Please review and commit!
>  >
>  >
>  > On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>  >>
>  >> Agreed.  Lets match J9 and RI for now.  We can always revisit as
> it will
>  >> be logged, right? :)
>  >>
>  >> Elena Semukhina wrote:
>  >> > As everyone keeps silence, I'd suggest to change
> implementation to be
>  >> bug
>  >> > compatible with RI.
>  >> >
>  >> > On 10/15/06, Elena Semukhina <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>  >> >>
>  >> >>
>  >> >>
>  >> >> On 10/14/06, Tim Ellison < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>  >> >>
>  >> >> > Elena Semukhina wrote:
>  >> >> > > Classlib test ThreadGroupTest.test_setMaxPriorityI ()
> fails on
>  >> DRLVM
>  >> >> > because
>  >> >> > > it expects behaviour that conflicts with specification.
>  >> >> > > The test passes on IBM VME and RI. The issue is reported
at
>  >> >> > > https://issues.apache.org/jira/browse/HARMONY-1625 .
>  >> >> > >
>  >> >> > > Actually there is a bug report in
>  >> >> > >
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which
>  >> >> > agreed
>  >> >> > > that
>  >> >> > > this is a bug in RI and it should be fixed.
>  >> >> > >
>  >> >> > > Should we follow RI's behaviour and change drlvm
>  >> ThreadGroup.javaor
>  >> >> > should
>  >> >> > > we fix the test?
>  >> >> >
>  >> >> > I'm off-line at the moment so cannot look at the bug
> details.  The
>  >> >> > question is whether fixing the 'bug' will likely break any
>  >> >> applications?
>  >> >>
>  >> >>
>  >> >> This question was discussed in Sun's bug report as well. A
> JCK test
>  >> >> detected this bug. The first evaluation stated that "This is
>  >> relatively
>  >> >> obscure functionality and it's theoretically possible at that
> changing
>  >> >> the
>  >> >> behavior will break running apps." The second evaluation
> suggested to
>  >> >> fix the implementation rather than change the spec. The bug
is in
>  >> >> progress
>  >> >> since 2002...
>  >> >>
>  >> >>
>  >> >>
>  >> >> > Regards,
>  >> >> > Tim
>  >> >> >
>  >> >> > --
>  >> >> >
>  >> >> > Tim Ellison ([EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> )
>  >> >> > IBM Java technology centre, UK.
>  >> >> >
>  >> >> >
>  >> >> >
>  >>
>
-
>  >> >> > Terms of use :
http://incubator.apache.org/harmony/mailing.html
>  >> >> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>  >> >> > For additional commands, e-mail:
>  >> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>  >> >> >
>  >> >> >
>  >> >>
>  >> >>
>  >> >> --
>  >> >> Thanks,
>  >> >> Elena
>  >> >
>  >> >
>  >> >
>  >> >
>  >>
>  >>
>
-
>  >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>  >> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>  >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>  >>
>  >>
>  >
>  >
>
>
>
>
> --
> Thanks,
> Elena





--
Thanks,
Elena

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

On 10/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Just to be clear - does J9 exhibit the same problem as the RI?



Yes, it does. The test passes on J9.


Elena Semukhina wrote:

> I attached two new patches to HARMONY-1625 which fix the test and copy
RI
> bug to drlvm ThreadGroup implementation :(
> Please review and commit!
>
>
> On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> Agreed.  Lets match J9 and RI for now.  We can always revisit as it
will
>> be logged, right? :)
>>
>> Elena Semukhina wrote:
>> > As everyone keeps silence, I'd suggest to change implementation to be
>> bug
>> > compatible with RI.
>> >
>> > On 10/15/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> On 10/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > Elena Semukhina wrote:
>> >> > > Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on
>> DRLVM
>> >> > because
>> >> > > it expects behaviour that conflicts with specification.
>> >> > > The test passes on IBM VME and RI. The issue is reported at
>> >> > > https://issues.apache.org/jira/browse/HARMONY-1625 .
>> >> > >
>> >> > > Actually there is a bug report in
>> >> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which
>> >> > agreed
>> >> > > that
>> >> > > this is a bug in RI and it should be fixed.
>> >> > >
>> >> > > Should we follow RI's behaviour and change drlvm
>> ThreadGroup.javaor
>> >> > should
>> >> > > we fix the test?
>> >> >
>> >> > I'm off-line at the moment so cannot look at the bug details.  The
>> >> > question is whether fixing the 'bug' will likely break any
>> >> applications?
>> >>
>> >>
>> >> This question was discussed in Sun's bug report as well. A JCK test
>> >> detected this bug. The first evaluation stated that "This is
>> relatively
>> >> obscure functionality and it's theoretically possible at that
changing
>> >> the
>> >> behavior will break running apps." The second evaluation suggested
to
>> >> fix the implementation rather than change the spec. The bug is in
>> >> progress
>> >> since 2002...
>> >>
>> >>
>> >>
>> >> > Regards,
>> >> > Tim
>> >> >
>> >> > --
>> >> >
>> >> > Tim Ellison ([EMAIL PROTECTED] )
>> >> > IBM Java technology centre, UK.
>> >> >
>> >> >
>> >> >
>> -
>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> >> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Thanks,
>> >> Elena
>> >
>> >
>> >
>> >
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>





--
Thanks,
Elena

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

I attached the patch to H-1931 which fixes algorithm of checking
accessibility. Please review!

On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:


I think getEnclosingClass returns null not because of the "strange"
name but because it doesn't generate the enclosing method attribute
for local classes.

Evgueni

On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> On Tuesday 24 October 2006 05:12 Nathan Beyer wrote:
> > By "inner class" you mean an automatic/local class in this case; a
> > class declared inside a method. It would seem appropriate that a local
> > class is declared private. Only the method that contains the class
> > declaration can see it.
> >
> > Do you disagree with what ECJ is generating?
>
> After reading this thread I think you are right and it is ok to generate
> private attribute for inner classes.
>
> There is another difference between compilers output. Sun compiler and
ECJ
> generate different class names for Test1931_2.java inner class. Sun
compiler
> creates Test1931_2$1LocalClass.class while ECJ creates
> Test1931_2$1$LocalClass.class.
>
> It might be not the cause of the bug in this case, but I wonder whether
naming
> of inner classes is specified somewhere. Shouldn't names be the same for
all
> compilers?
>
> > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
> > > > I haven't had a chance to look at the issue (JIRAs down right now,
> > > > probably part of the infrastructure move), but have you tried
> > > > comparing the actual class files of the problematic class or
classes.
> > > >
> > > > I'd suggest compiling the files using ECJ, save them off, compile
with
> > > > Sun/BEA/etc, save them off and then run javap from a single JDK on
> > > > each of the class files and compare them for differences.
> > >
> > > Yes, it is quite interesting how different compilers produce
different
> > > class attributes, it looks like this is the main problem with the
code.
> > > ECJ insists on marking inner classes private. Elena was kind to send
me
> > > another test which she wrote while JIRA was down and it shows even a
> > > bigger difference between the compilers - it produces different
output on
> > > RI. In the 2nd test ECJ creates an inner in anonymous class
> > > Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass.
This
> > > gives different output from cc.getEnclosingClass and cc.isLocalClass
> > > where cc is the used inner class.
> > >
> > > Nevertheless RI allows the access to the inner private class it
seems. It
> > > doesn't throw the exception which drlvm does. The exception source
is
> > > drlvm's kernel class ReflectExporter and the method in question is
> > > allowAccess which calls allowClassAccess at line 113. This check is
the
> > > one and the only chance to return true in this case.
> > >
> > > I've debugged the code with recently implemented debugging support
of
> > > drlvm using eclipse (jdwp agent has to be build for this from
> > > HARMONY-1410, also kernel classes for drlvm aren't compiled with
debug
> > > support, build script has to be hacked) but I just don't know all of
the
> > > access checks specification statements to make a decision which one
is
> > > not correct.
> > >
> > > P.S. I used ecj 3.2 which we use for current classlib compilation.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>





--
Thanks,
Elena

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
Nathan,I tend to agree with you. I believe even with "private" modifier setIllegalAccessException should not be thrown in the test case. What
really worries me is why getEnclosingClass returns null...it is a bugdefinitelyI think it should be resolved first...
 
I attached a test that demonstrates the bug in ECJ. It does not provide enclosing method and enclosing class info for local classes so we cannot rely on Class.getEnclosingClass() until the bug is fixed. May we hope for the quick fix?

EvgueniOn 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:> > I think we have several different items/questions to discuss:> >> > 1) Is it legal to generate "private" modifier to a local class?
> > The Java Language Specification, Third Edition part 14.3 states> > > > It is a compile-time error if a local class declaration contains any> > one of the following access modifiers: public, protected, private, or
> > static.> > > > So it seems a compiler isn't allowed to put "private" modifier. Thoughts?>> This is the part I was commenting, so I put my thoughts here. This is
> from the language specification and only applies to Java syntax and> yes, that's an error and it makes sense. But from the class file> (bytecode) perspective, a local class must be defined in its own file
> and this class is not accessible by any other class in the package> (not default or package-private scope), so I would think that it> should be marked private.>> My reasoning would be that the language spec is saying a class
> modifier is illegal for a local class because within the scope of a> method there is no concept or more or less accessible than the method.> Thus, if we promoted this concept to an inner class, it would be
> conceptually the same as a private inner class because it would be off> limits from other classes in the same package.>> I think what the language specification is say here is much like the
> scope identifiers of methods on an interface. If the interface is> public, all methods are public, even if they aren't declared public.>> >> > 2) getEnclosingClass and isLocalClass doesn't give correct result when
> > compiled with ECJ. It seems to be a seperate problem but this can> > affect the algorithm which determines member accessibility. Seems this> > should be resolved first.> >> > 3) Elena and I looked at the algorithm which determines member
> > accessibility and found a problem in it. To resolve the problem we> > need to fix getEnclosingClass. So I propose to concentrate on this> > method for now.> >> > Evgueni
> >> > On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:> > > By "inner class" you mean an automatic/local class in this case; a
> > > class declared inside a method. It would seem appropriate that a local> > > class is declared private. Only the method that contains the class> > > declaration can see it.> > >
> > > Do you disagree with what ECJ is generating?> > >> > > -Nathan> > >> > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]
> wrote:> > > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote:> > > > > I haven't had a chance to look at the issue (JIRAs down right now,> > > > > probably part of the infrastructure move), but have you tried
> > > > > comparing the actual class files of the problematic class or classes.> > > > >> > > > > I'd suggest compiling the files using ECJ, save them off, compile with
> > > > > Sun/BEA/etc, save them off and then run javap from a single JDK on> > > > > each of the class files and compare them for differences.> > > >> > > > Yes, it is quite interesting how different compilers produce different class
> > > > attributes, it looks like this is the main problem with the code. ECJ insists> > > > on marking inner classes private. Elena was kind to send me another test> > > > which she wrote while JIRA was down and it shows even a bigger difference
> > > > between the compilers - it produces different output on RI. In the 2nd test> > > > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun> > > > creates Test1931_2$1LocalClass. This gives different output from
> > > > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class.> > > >> > > > Nevertheless RI allows the access to the inner private class it seems. It
> > > > doesn't throw the exception which drlvm does. The exception source is drlvm's> > > > kernel class ReflectExporter and the method in question is allowAccess which> > > > calls allowClassAccess at line 113. This check is the one and the only chance
> > > > to return true in this case.> > > >> > > > I've debugged the code with recently implemented debugging support of drlvm> > > > using eclipse (jdwp agent has to be build for this from HARMONY-1410, also
> > > > kernel classes for drlvm aren't compiled with debug support, build script has> > > > to be hacked) but I just don't know all of the access checks spec

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:


I think we have several different items/questions to discuss:

1) Is it legal to generate "private" modifier to a local class?
The Java Language Specification, Third Edition part 14.3 states

It is a compile-time error if a local class declaration contains any
one of the following access modifiers: public, protected, private, or
static.

So it seems a compiler isn't allowed to put "private" modifier. Thoughts?



The spec says about class declaration but not compiled class modifiers.
Sun's compiler provides the "public" modifier for a local class while ECJ
sets it to "private", which seems more appropriate.

2) getEnclosingClass and isLocalClass doesn't give correct result when

compiled with ECJ. It seems to be a seperate problem but this can
affect the algorithm which determines member accessibility. Seems this
should be resolved first.

3) Elena and I looked at the algorithm which determines member
accessibility and found a problem in it. To resolve the problem we
need to fix getEnclosingClass. So I propose to concentrate on this
method for now.

Evgueni

On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> By "inner class" you mean an automatic/local class in this case; a
> class declared inside a method. It would seem appropriate that a local
> class is declared private. Only the method that contains the class
> declaration can see it.
>
> Do you disagree with what ECJ is generating?
>
> -Nathan
>
> On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
> > > I haven't had a chance to look at the issue (JIRAs down right now,
> > > probably part of the infrastructure move), but have you tried
> > > comparing the actual class files of the problematic class or
classes.
> > >
> > > I'd suggest compiling the files using ECJ, save them off, compile
with
> > > Sun/BEA/etc, save them off and then run javap from a single JDK on
> > > each of the class files and compare them for differences.
> >
> > Yes, it is quite interesting how different compilers produce different
class
> > attributes, it looks like this is the main problem with the code. ECJ
insists
> > on marking inner classes private. Elena was kind to send me another
test
> > which she wrote while JIRA was down and it shows even a bigger
difference
> > between the compilers - it produces different output on RI. In the 2nd
test
> > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while
Sun
> > creates Test1931_2$1LocalClass. This gives different output from
> > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner
class.
> >
> > Nevertheless RI allows the access to the inner private class it seems.
It
> > doesn't throw the exception which drlvm does. The exception source is
drlvm's
> > kernel class ReflectExporter and the method in question is allowAccess
which
> > calls allowClassAccess at line 113. This check is the one and the only
chance
> > to return true in this case.
> >
> > I've debugged the code with recently implemented debugging support of
drlvm
> > using eclipse (jdwp agent has to be build for this from HARMONY-1410,
also
> > kernel classes for drlvm aren't compiled with debug support, build
script has
> > to be hacked) but I just don't know all of the access checks
specification
> > statements to make a decision which one is not correct.
> >
> > P.S. I used ecj 3.2 which we use for current classlib compilation.
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
>





--
Thanks,
Elena

[drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

Hi all,

after classlib build system has switched to use ECJ, one test in swing
module started to fail on drlvm (win/linux). Actually the failure is not
related to swing functionality. I've filed JIRA issue
https://issues.apache.org/jira/browse/HARMONY-1931 and attached a simple
test to reproduce the failure.

All interested parties are welcome to look at this issue!

--
Thanks,
Elena

Re: [drlvm]"Debug Error!" dialog window occurs when running junit.awtui.TestRunner.

[Elena Semukhina]

I can confirm that 1916 it is not reproducible after I applied 1483.

On 10/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> I tried this patch too, it works! HARMONY-1916 can be closed as a
> duplicate.

Marked as dupe.

Regards,
Tim


--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm]"Debug Error!" dialog window occurs when running junit.awtui.TestRunner.

[Elena Semukhina]

I tried this patch too, it works! HARMONY-1916 can be closed as a duplicate.

On 10/20/06, Ilya Okomin <[EMAIL PROTECTED]> wrote:


On 10/19/06, Dmitry Durnev <[EMAIL PROTECTED]> wrote:
>
> I think issue HARMONY-1483 has the necessary patch attached, but not
> applied yet.


Dmitry, thanks a lot!
Suggested patch makes TestRunner work!
Committers should also take a look at this patch.

Regards,
Ilya.

On 10/19/06, Ilya Okomin <[EMAIL PROTECTED]> wrote:
> > Hi all!
> >
> > I was trying to run junit.awtui.TestRunner on the latest
classlib+drlvm
> and
> > had got "Debug Error!" window with next message:
> > "DAMAGE: after Normal block (#108135) at 0x04263008.". If all these
> messages
> > (they are the same with changed #... and 0x... values) ignored
> TestRunner
> > application appears and it works.
> >
> > Steps to reproduce:
> > 1. Copy junit.jar to deploy/jdk/jre/bin
> > 2. Call "java -cp junit.jar junit.awtui.TestRunner" in the
> > deploy/jdk/jre/bin.
> >
> > I want to note that junit.awtui.TestRunner works fine with J9.
> > I found opened issue HARMONY-1916 [1] with the same dialog window
> occured.
> >
> > Does anyone know the reason of these errors?
> >
> > [1] http://issues.apache.org/jira/browse/HARMONY-1916
> > --
> > --
> > Ilya Okomin
> > Intel Middleware Products Division
> >
> >
>
>
> --
>
> Dmitry A. Durnev,
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
--
Ilya Okomin
Intel Middleware Products Division





--
Thanks,
Elena

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:




Elena Semukhina wrote:
> It's a nightmare to run classlib tests on drlvm now. They crash and are
> interrupted and hang...

What changed?



Nothing new, this is an old story. If you remember, things changed about 2
weeks ago after H-1582 commit. That patch revealed some issues and since
that it's hard to run classlib tests. Adding swing/awt tests aggravated the
situation: they are rather sensitive to H-1823.


I've applied some patches which solve these issues
> and got quite acceptable results on Windows 2003 server. I've excluded
some
> tests which crash and hang because patches for them are not ready yet so
we
> have about 50 tests less in the table than on IBM VM. The results are on
> the
> page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM, in the
> October, 19 table.

That's impressive.



Our goal is 100% :)

geir


>
> On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> which patch of the two should be applied?  Or both? (please respond on
>> the JIRA...)
>>
>> Elena Semukhina wrote:
>> > HARMONY-1823 is ready for commit. It will increase classlib pass rate
>> > significantly!
>> >
>> > On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I added one more issue to
>> >> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is
>> >> http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM
>> issue
>> >> and will cause the ThreadGroupTest failure after HARMONY-1625 is
>> applied.
>> >> Could anyone look at this issue?
>> >>
>> >> On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > It seems that the patch for
>> >> HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
>> >> > ready and the patch for
>> >> HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
>> >> > waiting for Alexey Varlamov's evaluation.
>> >> >
>> >> > On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED] >
wrote:
>> >> > >
>> >> > > Oops, review of HARMONY-1823 should be:
>> >> > > The fix is to clean an interrupt flag. Patches are good.
>> >> > >
>> >> > > With best regards,
>> >> > > Alexei Fedotov,
>> >> > > Intel Middleware Products Division
>> >> > >
>> >> > > >-Original Message-
>> >> > > >From: Fedotov, Alexei A
>> >> > > >Sent: Friday, October 13, 2006 6:12 PM
>> >> > > >To: [EMAIL PROTECTED]
>> >> > > >Cc: harmony-dev@incubator.apache.org
>> >> > > >Subject: RE: [drlvm][unit tests] the goal is to achieve 100%
pass
>> >> > > rate
>> >> > > >
>> >> > > >Geir,
>> >> > > >I reviewed the patches for HARMONY-1816 (non-daemon thread
>> counting
>> >> > > is
>> >> > > done
>> >> > > >more accurately) and for HARMONY-1823 - the fix is to clean
>> patches
>> >> > > are
>> >> > > >good.
>> >> > > >
>> >> > > >I believe the patches worth to be committed: I've tried the
>> patches
>> >> > > for
>> >> > > >running tests from luni module 162 times and get the following
>> >> > > results:
>> >> > > >
>> >> > > >$ grep FAILED luni.log  | sort | uniq -c
>> >> > > > 63 [junit] TEST
>> >> > > >org.apache.harmony.tests.internal.net.www.protocol.http
>> >> > > >.HttpURLConnectionTest FAILED
>> >> > > >162 [junit] TEST tests.api.java.lang.reflect.FieldTest
>> >> FAILED
>> >> > > >  6 [junit] TEST tests.api.java.net.InetAddressTest
>> FAILED
>> >> > > >
>> >> > > >The following tests were excluded:
>> >> > > >Index: modules/luni/build.xml
>> >> > >
>> >===
>> >> > > >--- modules/luni/build.xml  (revision 463342)
>> >> > > >+++ modules/luni/build.xml  (working copy)
>> >> > > >@@ -325,6 +325,14 @@
>> >> > > &

Re: [classlib][portlib] classlib tests fail on portlib

[Elena Semukhina]

Weldon,
Mark's fix solved the issue I reported! Never mind!


On 10/19/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:


I committed the mods that add the portlib module.  I take it that Mark
Hindess has fixed the "ant test" problem.  I just now did an "svn update",
ant and "ant test".  It fails on what looks like a non-portlib related
problem.  Please let me know if I need to do anything to help.  Sorry for
the inconvenience.

   Weldon

compile-tests:
[echo] Compiling ACCESSIBILITY tests
   [mkdir] Created dir:
C:\t_harmony\classlib\trunk\modules\accessibility\bin\t
est
   [javac] Compiling 8 source files to
C:\t_harmony\classlib\trunk\modules\acce
ssibility\bin\test
   [javac] Since fork is false, ignoring memoryMaximumSize setting
   [javac] --
   [javac] 1. ERROR in
C:\t_harmony\classlib\trunk\modules\accessibility\src\te
st\api\java\common\javax\accessibility\AccessibleBundleTest.java
   [javac]  (at line 27)
   [javac] public class AccessibleBundleTest extends
BasicSwingTestCase
{
   [javac]
^^
   [javac] The type junit.framework.TestCase cannot be resolved. It is
indirect
ly referenced from required .class files
   [javac] --
   [javac] 1 problem (1 error)



On 10/19/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>
>
> On 19 October 2006 at 16:14, "Elena Semukhina" <
[EMAIL PROTECTED]>
> wrote:
> >
> > After the portlib module has been added today to
> > classlib/trunk/modules "ant test" started failing on this module with
> > the message "Target `test' does not exist in this project. "
>
> This should be fixed in r465546. ("ant -Dbuild.module=portlib test" will
> still fail since portlib has no tests but "ant test" should complete.)
>
> I think it might be nice to add some (native) tests to portlib since
> this would aid porting to new platforms.  What do other people think?
>
> Regards,
> Mark.
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Weldon Washburn
Intel Middleware Products Division





--
Thanks,
Elena

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

It's a nightmare to run classlib tests on drlvm now. They crash and are
interrupted and hang... I've applied some patches which solve these issues
and got quite acceptable results on Windows 2003 server. I've excluded some
tests which crash and hang because patches for them are not ready yet so we
have about 50 tests less in the table than on IBM VM. The results are on the
page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM, in the
October, 19 table.

On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


which patch of the two should be applied?  Or both? (please respond on
the JIRA...)

Elena Semukhina wrote:
> HARMONY-1823 is ready for commit. It will increase classlib pass rate
> significantly!
>
> On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>>
>> I added one more issue to
>> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is
>> http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue
>> and will cause the ThreadGroupTest failure after HARMONY-1625 is
applied.
>> Could anyone look at this issue?
>>
>> On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >
>> > It seems that the patch for
>> HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
>> > ready and the patch for
>> HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
>> > waiting for Alexey Varlamov's evaluation.
>> >
>> > On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED] > wrote:
>> > >
>> > > Oops, review of HARMONY-1823 should be:
>> > > The fix is to clean an interrupt flag. Patches are good.
>> > >
>> > > With best regards,
>> > > Alexei Fedotov,
>> > > Intel Middleware Products Division
>> > >
>> > > >-Original Message-
>> > > >From: Fedotov, Alexei A
>> > > >Sent: Friday, October 13, 2006 6:12 PM
>> > > >To: [EMAIL PROTECTED]
>> > > >Cc: harmony-dev@incubator.apache.org
>> > > >Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass
>> > > rate
>> > > >
>> > > >Geir,
>> > > >I reviewed the patches for HARMONY-1816 (non-daemon thread
counting
>> > > is
>> > > done
>> > > >more accurately) and for HARMONY-1823 - the fix is to clean
patches
>> > > are
>> > > >good.
>> > > >
>> > > >I believe the patches worth to be committed: I've tried the
patches
>> > > for
>> > > >running tests from luni module 162 times and get the following
>> > > results:
>> > > >
>> > > >$ grep FAILED luni.log  | sort | uniq -c
>> > > > 63 [junit] TEST
>> > > >org.apache.harmony.tests.internal.net.www.protocol.http
>> > > >.HttpURLConnectionTest FAILED
>> > > >162 [junit] TEST tests.api.java.lang.reflect.FieldTest
>> FAILED
>> > > >  6 [junit] TEST tests.api.java.net.InetAddressTest FAILED
>> > > >
>> > > >The following tests were excluded:
>> > > >Index: modules/luni/build.xml
>> > >
>===
>> > > >--- modules/luni/build.xml  (revision 463342)
>> > > >+++ modules/luni/build.xml  (working copy)
>> > > >@@ -325,6 +325,14 @@
>> > > > > > > >name="tests/api/java/net/URLConnectionTest.jav
>> > > >a" />
>> > > > > > > name="tests/api/java/net/URLTest.java" />
>> > > > > > > >name="tests/api/java/net/SocketPermissionTest.
>> > > >java" />
>> > > >+
>> > > >+> > > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
>> > > >+> > > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
>> > > >+> > >
>name="org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java"
>> > > />
>> > > >
>> > > >+> > >
>name="org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java"
>> > > />
>> > > >
>> > > >+> > > name="org/apache/harmony/luni/tests/java/lang/ClassTest.java"
>> > > />
>> > > >+
&g

[classlib][portlib] classlib tests fail on portlib

[Elena Semukhina]

After the portlib module has been added today to classlib/trunk/modules "ant
test" started failing on this module with the message
"Target `test' does not exist in this project. "

--
Thanks,
Elena

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Elena Semukhina]

On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


My 2003 server is installed on a single core P4 with HT. The test attached
to HARMONY-1669 works fine for me both with and without patch :)

I may get an access to dual core server as described in JIRA but I am
afraid
it will take a few days. Probably we can just apply the patch since it
doesn't seem to do any harm.



Indeed the attached test passes and PipedInputStream test passes being run
separately now but when I ran the whole luni module, it hung. I applied the
patch and it helped.

2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>:

>
>
>
> Rana Dasgupta wrote:
> > On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >>
> >> So since I don't have Win 2003, I gotta just commit and let someone
> else
> >> test?
> >>
> >> Any committer have win 2003?
> >
> >
> > I think that it may be hard to find a test at this point that fails on
> > Windows Server 2003, but passes on XP. But perf etc. characteristics
> > will be
> > different. At some point, gc_v5 etc. is likely to have server specific
> > variations, eg., parallel gc may be on server only.
> >
> > Are we talking of tests in general? I am sorry, but I may not have
> > understood the comment.
>
> There is a test that demonstrates a Win 2003 bug...  I can just commit
> it and let someone confirm since I don't have a win 2003 machine
>
> geir
>


--
Gregory Shimansky, Intel Middleware Products Division





--
Thanks,
Elena

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

I attached two new patches to HARMONY-1625 which fix the test and copy RI
bug to drlvm ThreadGroup implementation :(
Please review and commit!


On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Agreed.  Lets match J9 and RI for now.  We can always revisit as it will
be logged, right? :)

Elena Semukhina wrote:
> As everyone keeps silence, I'd suggest to change implementation to be
bug
> compatible with RI.
>
> On 10/15/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 10/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>
>> > Elena Semukhina wrote:
>> > > Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM
>> > because
>> > > it expects behaviour that conflicts with specification.
>> > > The test passes on IBM VME and RI. The issue is reported at
>> > > https://issues.apache.org/jira/browse/HARMONY-1625 .
>> > >
>> > > Actually there is a bug report in
>> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which
>> > agreed
>> > > that
>> > > this is a bug in RI and it should be fixed.
>> > >
>> > > Should we follow RI's behaviour and change drlvm ThreadGroup.javaor
>> > should
>> > > we fix the test?
>> >
>> > I'm off-line at the moment so cannot look at the bug details.  The
>> > question is whether fixing the 'bug' will likely break any
>> applications?
>>
>>
>> This question was discussed in Sun's bug report as well. A JCK test
>> detected this bug. The first evaluation stated that "This is relatively
>> obscure functionality and it's theoretically possible at that changing
>> the
>> behavior will break running apps." The second evaluation suggested to
>> fix the implementation rather than change the spec. The bug is in
>> progress
>> since 2002...
>>
>>
>>
>> > Regards,
>> > Tim
>> >
>> > --
>> >
>> > Tim Ellison ([EMAIL PROTECTED] )
>> > IBM Java technology centre, UK.
>> >
>> >
>> > -
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail:
[EMAIL PROTECTED]
>> >
>> >
>>
>>
>> --
>> Thanks,
>> Elena
>
>
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

HARMONY-1720 patch has been evaluated by Alexey Varlamov and could be
committed too.


On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


HARMONY-1823 is ready for commit. It will increase classlib pass rate
significantly!

On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> I added one more issue to
> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is 
http://issues.apache.org/jira/browse/HARMONY-1648
> . It is drlvm/TM issue and will cause the ThreadGroupTest failure after
> HARMONY-1625 is applied. Could anyone look at this issue?
>
> On 10/17/06, Elena Semukhina <[EMAIL PROTECTED] > wrote:
> >
> > It seems that the patch for 
HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
> > ready and the patch for 
HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
> > waiting for Alexey Varlamov's evaluation.
> >
> > On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED] > wrote:
> > >
> > > Oops, review of HARMONY-1823 should be:
> > > The fix is to clean an interrupt flag. Patches are good.
> > >
> > > With best regards,
> > > Alexei Fedotov,
> > > Intel Middleware Products Division
> > >
> > > >-Original Message-
> > > >From: Fedotov, Alexei A
> > > >Sent: Friday, October 13, 2006 6:12 PM
> > > >To: [EMAIL PROTECTED]
> > > >Cc: harmony-dev@incubator.apache.org
> > > >Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass
> > > rate
> > > >
> > > >Geir,
> > > >I reviewed the patches for HARMONY-1816 (non-daemon thread counting
> > > is
> > > done
> > > >more accurately) and for HARMONY-1823 - the fix is to clean patches
> > > are
> > > >good.
> > > >
> > > >I believe the patches worth to be committed: I've tried the patches
> > > for
> > > >running tests from luni module 162 times and get the following
> > > results:
> > > >
> > > >$ grep FAILED luni.log  | sort | uniq -c
> > > > 63 [junit] TEST
> > > >org.apache.harmony.tests.internal.net.www.protocol.http
> > > >.HttpURLConnectionTest FAILED
> > > >162 [junit] TEST tests.api.java.lang.reflect.FieldTestFAILED
> > > >  6 [junit] TEST tests.api.java.net.InetAddressTest FAILED
> > > >
> > > >The following tests were excluded:
> > > >Index: modules/luni/build.xml
> > > >===
> > >
> > > >--- modules/luni/build.xml  (revision 463342)
> > > >+++ modules/luni/build.xml  (working copy)
> > > >@@ -325,6 +325,14 @@
> > > >  > > >name="tests/api/java/net/URLConnectionTest.jav
> > > >a" />
> > > >  > > name="tests/api/java/net/URLTest.java" />
> > > >  > > >name="tests/api/java/net/SocketPermissionTest.
> > > >java" />
> > > >+
> > > >+ > > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> > > >+ > > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> > > >+ > > >name="org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java"
> > > />
> > > >
> > > >+ > > >name="org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java"
> > > />
> > > >
> > > >+ > > name="org/apache/harmony/luni/tests/java/lang/ClassTest.java"
> > > />
> > > >+
> > > >+
> > > > 
> > > > 
> > > >
> > > >With best regards,
> > > >Alexei Fedotov,
> > > >Intel Middleware Products Division
> > > >
> > > >>-Original Message-----
> > > >>From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED]
> > > >>Sent: Friday, October 13, 2006 9:58 AM
> > > >>To: harmony-dev@incubator.apache.org
> > > >>Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass
> > > rate
> > > >>
> > > >>great work - we'll get those applied ASAP.
> > > >>
> > > >>Elena Semukhina wrote:
> > > >>> Yesterday I tried the following patches:
> >

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Elena Semukhina]

On 10/17/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:


We have mighty guys on this list. Why cannot we just fix these tests
instead of excluding them?

I suggest starting with basic threading issues such as
org.apache.harmony.luni.tests.java.lang.ThreadTest,
org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably
fail in my environment. I volunteer for checking reliability of fixes.



The ThreadTest fails stabily due to HARMONY-1789 and intermittently due to
HARMONY-1876 (the test's problem).
I've never seen the ThreadGroupTest failure.

Gregory asked why this test fails on RI too. It looks like the RI
implementation of Thread.destroy() and ThreadInterrupt() for new, terminated
and current thread contradicts the spec. RI failures on getState() look
unexpected. I'll look at the test.


With best regards,

Alexei Fedotov,
Intel Middleware Products Division

>-Original Message-
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 17, 2006 12:01 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>
>
>Gregory Shimansky wrote:
>> Hello
>>
>> After reading several threads about drlvm tests failing for quite a
while
>I
>> decided we need to exclude them temporarily until the bugs are fixed.
>When on
>> test fails, it means that other are not run after it because drlvm
has
>> several sets of tests which run in different modes, so there are many
>test
>> runs in one "build test" command. When some test doesn't work for
quite
>some
>> time it means that other may not be ran for this period and we can
get
>more
>> failures accidently.
>
>That's actually not true.  I never commit unless all tests (minus some
>kernel tests) run.
>
>The Finalizer and PhanRefQueueTest are flakey - I always repeat until
>the passed, so the rest could run.   I'm just sick of it, so i did the
>magic @keyword attribute and committed.
>
>>
>> Excluding tests is not good, but not running some basic commit checks
is
>> worse, so I think we need to disable them until the bugs are fixed.
So
>far I
>> know about 3 tests which fail for sure:
>>
>> gc.LOS - stably hangs on windows XP
>> gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect
CCE
>> condition detected, fail with rate less than 100%. Ok I've just read
that
>> Geir has excluded them already
>>
>> Are there any other tests which don't work perfectly to do a clean
tests
>run?
>> I think we need it do make minimal commit checks for drlvm.
>>
>> I've seen java.lang.ThreadTest in kernel tests to output something
that
>it has
>> failed on reference JRE. Is this test correct if it doesn't work on
RI?
>The
>> failure however doesn't seem to make test run to fail so maybe we
could
>leave
>> this test for now.
>>
>> I also have a question about 15 smoke tests excluded with XXX or
X_int
>> keywords. They've been disabled since I remember. Is there any reason
why
>> they aren't included in test runs?
>
>I tried to put some back.  StackTest still doesn't work.  It's hard to
>believe...   so I gave up and just kept going :)
>
>geir
>
>>
>
>-
>Terms of use : http://incubator.apache.org/harmony/mailing.html
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

As everyone keeps silence, I'd suggest to change implementation to be bug
compatible with RI.

On 10/15/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:




On 10/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

> Elena Semukhina wrote:
> > Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM
> because
> > it expects behaviour that conflicts with specification.
> > The test passes on IBM VME and RI. The issue is reported at
> > https://issues.apache.org/jira/browse/HARMONY-1625 .
> >
> > Actually there is a bug report in
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which
> agreed
> > that
> > this is a bug in RI and it should be fixed.
> >
> > Should we follow RI's behaviour and change drlvm ThreadGroup.java or
> should
> > we fix the test?
>
> I'm off-line at the moment so cannot look at the bug details.  The
> question is whether fixing the 'bug' will likely break any applications?


This question was discussed in Sun's bug report as well. A JCK test
detected this bug. The first evaluation stated that "This is relatively
obscure functionality and it's theoretically possible at that changing the
behavior will break running apps." The second evaluation suggested to
fix the implementation rather than change the spec. The bug is in progress
since 2002...



> Regards,
> Tim
>
> --
>
> Tim Ellison ([EMAIL PROTECTED] )
> IBM Java technology centre, UK.
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Thanks,
Elena





--
Thanks,
Elena

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

HARMONY-1823 is ready for commit. It will increase classlib pass rate
significantly!

On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


I added one more issue to
http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is
http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue
and will cause the ThreadGroupTest failure after HARMONY-1625 is applied.
Could anyone look at this issue?

On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> It seems that the patch for 
HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
> ready and the patch for 
HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
> waiting for Alexey Varlamov's evaluation.
>
> On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED] > wrote:
> >
> > Oops, review of HARMONY-1823 should be:
> > The fix is to clean an interrupt flag. Patches are good.
> >
> > With best regards,
> > Alexei Fedotov,
> > Intel Middleware Products Division
> >
> > >-Original Message-
> > >From: Fedotov, Alexei A
> > >Sent: Friday, October 13, 2006 6:12 PM
> > >To: [EMAIL PROTECTED]
> > >Cc: harmony-dev@incubator.apache.org
> > >Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass
> > rate
> > >
> > >Geir,
> > >I reviewed the patches for HARMONY-1816 (non-daemon thread counting
> > is
> > done
> > >more accurately) and for HARMONY-1823 - the fix is to clean patches
> > are
> > >good.
> > >
> > >I believe the patches worth to be committed: I've tried the patches
> > for
> > >running tests from luni module 162 times and get the following
> > results:
> > >
> > >$ grep FAILED luni.log  | sort | uniq -c
> > > 63 [junit] TEST
> > >org.apache.harmony.tests.internal.net.www.protocol.http
> > >.HttpURLConnectionTest FAILED
> > >162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED
> > >  6 [junit] TEST tests.api.java.net.InetAddressTest FAILED
> > >
> > >The following tests were excluded:
> > >Index: modules/luni/build.xml
> > >===
> > >--- modules/luni/build.xml  (revision 463342)
> > >+++ modules/luni/build.xml  (working copy)
> > >@@ -325,6 +325,14 @@
> > >  > >name="tests/api/java/net/URLConnectionTest.jav
> > >a" />
> > >  > name="tests/api/java/net/URLTest.java" />
> > >  > >name="tests/api/java/net/SocketPermissionTest.
> > >java" />
> > >+
> > >+ > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> > >+ > name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> > >+ > >name="org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java"
> > />
> > >
> > >+ > >name="org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java"
> > />
> > >
> > >+ > name="org/apache/harmony/luni/tests/java/lang/ClassTest.java"
> > />
> > >+
> > >+
> > > 
> > > 
> > >
> > >With best regards,
> > >Alexei Fedotov,
> > >Intel Middleware Products Division
> > >
> > >>-Original Message-
> > >>From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED]
> > >>Sent: Friday, October 13, 2006 9:58 AM
> > >>To: harmony-dev@incubator.apache.org
> > >>Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass
> > rate
> > >>
> > >>great work - we'll get those applied ASAP.
> > >>
> > >>Elena Semukhina wrote:
> > >>> Yesterday I tried the following patches:
> > >>>
> > >>> http://issues.apache.org/jira/browse/HARMONY-1592
> > >>> http://issues.apache.org/jira/browse/HARMONY-1816
> > >>> http://issues.apache.org/jira/browse/HARMONY-1823
> > >>> https://issues.apache.org/jira/browse/HARMONY-1741
> > >>>
> > >>> They work fine. The first three patches restore recent classlib
> > tests
> > >>pass
> > >>> rate degradation.
> > >>>
> > >>> On 10/11/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote:
> > >>>
> > >>>&

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

I added one more issue to
http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM. It is
http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue and
will cause the ThreadGroupTest failure after HARMONY-1625 is applied. Could
anyone look at this issue?

On 10/17/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


It seems that the patch for 
HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
ready and the patch for 
HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
waiting for Alexey Varlamov's evaluation.

On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
>
> Oops, review of HARMONY-1823 should be:
> The fix is to clean an interrupt flag. Patches are good.
>
> With best regards,
> Alexei Fedotov,
> Intel Middleware Products Division
>
> >-Original Message-
> >From: Fedotov, Alexei A
> >Sent: Friday, October 13, 2006 6:12 PM
> >To: [EMAIL PROTECTED]
> >Cc: harmony-dev@incubator.apache.org
> >Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate
> >
> >Geir,
> >I reviewed the patches for HARMONY-1816 (non-daemon thread counting is
> done
> >more accurately) and for HARMONY-1823 - the fix is to clean patches are
> >good.
> >
> >I believe the patches worth to be committed: I've tried the patches for
> >running tests from luni module 162 times and get the following results:
>
> >
> >$ grep FAILED luni.log  | sort | uniq -c
> > 63 [junit] TEST
> >org.apache.harmony.tests.internal.net.www.protocol.http
> >.HttpURLConnectionTest FAILED
> >162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED
> >  6 [junit] TEST tests.api.java.net.InetAddressTest FAILED
> >
> >The following tests were excluded:
> >Index: modules/luni/build.xml
> >===
> >--- modules/luni/build.xml  (revision 463342)
> >+++ modules/luni/build.xml  (working copy)
> >@@ -325,6 +325,14 @@
> >  >name="tests/api/java/net/URLConnectionTest.jav
> >a" />
> >  name="tests/api/java/net/URLTest.java" />
> >  >name="tests/api/java/net/SocketPermissionTest.
> >java" />
> >+
> >+ name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> >+ name="org/apache/harmony/luni/tests/java/lang/ThreadTest.java" />
> >+ >name="org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java" />
> >
> >+ >name="org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java" />
> >
> >+ />
> >+
> >+
> >     
> > 
> >
> >With best regards,
> >Alexei Fedotov,
> >Intel Middleware Products Division
> >
> >>-Original Message-
> >>From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED]
> >>Sent: Friday, October 13, 2006 9:58 AM
> >>To: harmony-dev@incubator.apache.org
> >>Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
>
> >>
> >>great work - we'll get those applied ASAP.
> >>
> >>Elena Semukhina wrote:
> >>> Yesterday I tried the following patches:
> >>>
> >>> http://issues.apache.org/jira/browse/HARMONY-1592
> >>> http://issues.apache.org/jira/browse/HARMONY-1816
> >>> http://issues.apache.org/jira/browse/HARMONY-1823
> >>> https://issues.apache.org/jira/browse/HARMONY-1741
> >>>
> >>> They work fine. The first three patches restore recent classlib
> tests
> >>pass
> >>> rate degradation.
> >>>
> >>> On 10/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Excellent.  As appreciative as I am of J9, I can't wait to work in
> >>>> all-Harmony code :)
> >>>>
> >>>> geir
> >>>>
> >>>>
> >>>> Elena Semukhina wrote:
> >>>> > Hello all,
> >>>> >
> >>>> > I think that the goal of running classlib unit tests on DRLVM
> with
> >>100%
> >>>> > pass
> >>>> > rate could be worth to achieve. Actually today we have 99%
> (without
> >>>> > awt/swing) but still have about 30 failures/errors. Most of them
> have
> >>>> been
> >>>> > evaluated and corresponding JIRAs filed. There is a page on
&g

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

It seems that the patch for
HARMONY-1751<http://issues.apache.org/jira/browse/HARMONY-1751> is
ready and the patch for
HARMONY-1720<http://issues.apache.org/jira/browse/HARMONY-1751> is
waiting for Alexey Varlamov's evaluation.

On 10/13/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:


Oops, review of HARMONY-1823 should be:
The fix is to clean an interrupt flag. Patches are good.

With best regards,
Alexei Fedotov,
Intel Middleware Products Division

>-Original Message-
>From: Fedotov, Alexei A
>Sent: Friday, October 13, 2006 6:12 PM
>To: [EMAIL PROTECTED]
>Cc: harmony-dev@incubator.apache.org
>Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate
>
>Geir,
>I reviewed the patches for HARMONY-1816 (non-daemon thread counting is
done
>more accurately) and for HARMONY-1823 - the fix is to clean patches are
>good.
>
>I believe the patches worth to be committed: I've tried the patches for
>running tests from luni module 162 times and get the following results:
>
>$ grep FAILED luni.log  | sort | uniq -c
> 63 [junit] TEST
>org.apache.harmony.tests.internal.net.www.protocol.http
>.HttpURLConnectionTest FAILED
>162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED
>  6 [junit] TEST tests.api.java.net.InetAddressTest FAILED
>
>The following tests were excluded:
>Index: modules/luni/build.xml
>===
>--- modules/luni/build.xml  (revision 463342)
>+++ modules/luni/build.xml  (working copy)
>@@ -325,6 +325,14 @@
> name="tests/api/java/net/URLConnectionTest.jav
>a" />
> 
> name="tests/api/java/net/SocketPermissionTest.
>java" />
>+
>+
>+
>+name="org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java" />
>
>+name="org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java" />
>
>+
>+
>+
> 
> 
>
>With best regards,
>Alexei Fedotov,
>Intel Middleware Products Division
>
>>-Original Message-
>>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>>Sent: Friday, October 13, 2006 9:58 AM
>>To: harmony-dev@incubator.apache.org
>>Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
>>
>>great work - we'll get those applied ASAP.
>>
>>Elena Semukhina wrote:
>>> Yesterday I tried the following patches:
>>>
>>> http://issues.apache.org/jira/browse/HARMONY-1592
>>> http://issues.apache.org/jira/browse/HARMONY-1816
>>> http://issues.apache.org/jira/browse/HARMONY-1823
>>> https://issues.apache.org/jira/browse/HARMONY-1741
>>>
>>> They work fine. The first three patches restore recent classlib
tests
>>pass
>>> rate degradation.
>>>
>>> On 10/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>>
>>>> Excellent.  As appreciative as I am of J9, I can't wait to work in
>>>> all-Harmony code :)
>>>>
>>>> geir
>>>>
>>>>
>>>> Elena Semukhina wrote:
>>>> > Hello all,
>>>> >
>>>> > I think that the goal of running classlib unit tests on DRLVM
with
>>100%
>>>> > pass
>>>> > rate could be worth to achieve. Actually today we have 99%
(without
>>>> > awt/swing) but still have about 30 failures/errors. Most of them
have
>>>> been
>>>> > evaluated and corresponding JIRAs filed. There is a page on
Harmony
>>>> Wiki
>>>> > which lists those JIRA issues:
>>>> >
>>>> > http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
>>>> >
>>>> > Are there any volunteers to help with DRLVM bugs fixing?
>>>> >
>>>> > Thanks,
>>>> > Elena
>>>> >
>>>>
>>>>
-
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail:
[EMAIL PROTECTED]
>>>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>
>>-
>>Terms of use : http://incubator.apache.org/harmony/mailing.html
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

On 10/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM
because
> it expects behaviour that conflicts with specification.
> The test passes on IBM VME and RI. The issue is reported at
> https://issues.apache.org/jira/browse/HARMONY-1625.
>
> Actually there is a bug report in
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed
> that
> this is a bug in RI and it should be fixed.
>
> Should we follow RI's behaviour and change drlvm ThreadGroup.java or
should
> we fix the test?

I'm off-line at the moment so cannot look at the bug details.  The
question is whether fixing the 'bug' will likely break any applications?



This question was discussed in Sun's bug report as well. A JCK test detected
this bug. The first evaluation stated that "This is relatively obscure
functionality and it's theoretically possible at that changing the behavior
will break running apps." The second evaluation suggested to fix the
implementation rather than change the spec. The bug is in progress since
2002...




Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

[classlib][tools][test] newly added KeyStoreLoaderSaverTest.java is not compiled

[Elena Semukhina]

Hi all,

I could not run classlib tests today because of compilation error described
at

*http://issues.apache.org/jira/browse/HARMONY-1855*
Could anyone fix the issue?

--
Thanks,
Elena

Re: [drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

Yesterday I tried the following patches:

http://issues.apache.org/jira/browse/HARMONY-1592
http://issues.apache.org/jira/browse/HARMONY-1816
http://issues.apache.org/jira/browse/HARMONY-1823
https://issues.apache.org/jira/browse/HARMONY-1741

They work fine. The first three patches restore recent classlib tests pass
rate degradation.

On 10/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Excellent.  As appreciative as I am of J9, I can't wait to work in
all-Harmony code :)

geir


Elena Semukhina wrote:
> Hello all,
>
> I think that the goal of running classlib unit tests on DRLVM with 100%
> pass
> rate could be worth to achieve. Actually today we have 99% (without
> awt/swing) but still have about 30 failures/errors. Most of them have
been
> evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki
> which lists those JIRA issues:
>
> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
>
> Are there any volunteers to help with DRLVM bugs fixing?
>
> Thanks,
> Elena
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [classlib][util.prefs] Implementation should be compatible with RI

[Elena Semukhina]

The test patch has been attached to HARMONY-1751.

On 10/12/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


Actually I'm trying to attach a patch to my own issue. And a few days ago
I successfully attached a patch to other's issue...

On 10/12/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
>
> Elena Semukhina wrote:
> > I prepared the patch for the test and a sample patch for
> implementation
> > which enables the test passing on IBM VME. As I'm not an expert in
> > util.prefs, I'd like someone to review the patch and add a warning
> message.
> >
> > Unfortunately I did not manage to upload attachments to H-1751; got
> the
> > mesage:
> >
> > Exception trying to establish attachment directory. Check that the
> > application server and JIRA have permissions to write to it:
> > com.atlassian.jira.web.util.AttachmentException : Cannot write to
> attachment
> > directory. Check that the application server and JIRA have permissions
> to
> > write to:
> /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751
> > Are
> > there any problems with attachment directory?
> > I'll make another try later.
>
> I suspect this is the way JIRA suggest that you file a new issue,
> so that issue has just one contributor / patch submitter.
>
> I've seen that message when trying to attach files to issue filed
> by someone else. Attaching to one's own issues works okay.
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Thanks,
Elena





--
Thanks,
Elena

[drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Elena Semukhina]

Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM because
it expects behaviour that conflicts with specification.
The test passes on IBM VME and RI. The issue is reported at
https://issues.apache.org/jira/browse/HARMONY-1625.

Actually there is a bug report in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed that
this is a bug in RI and it should be fixed.

Should we follow RI's behaviour and change drlvm ThreadGroup.java or should
we fix the test?

--
Thanks,
Elena

Re: [jira] Problem attaching patch

[Elena Semukhina]

I face the same problem.

On 10/12/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote:


Hi to everybody,

I am trying to attach patch with fix to HARMONY-1797 and I get the
following error message from JIRA:

Errors

   * Exception trying to establish attachment directory. Check that the
application server and JIRA have permissions to write to it:
com.atlassian.jira.web.util.AttachmentException: Cannot write to
attachment directory. Check that the application server and JIRA have
permissions to write to:
/usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1797


Could anyone please check that everything is OK there?

Thank you in advance,
Alexey.


--
Alexey A. Ivanov
Intel Middleware Product Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [classlib][util.prefs] Implementation should be compatible with RI

[Elena Semukhina]

Actually I'm trying to attach a patch to my own issue. And a few days ago I
successfully attached a patch to other's issue...

On 10/12/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:


Elena Semukhina wrote:
> I prepared the patch for the test and a sample patch for implementation
> which enables the test passing on IBM VME. As I'm not an expert in
> util.prefs, I'd like someone to review the patch and add a warning
message.
>
> Unfortunately I did not manage to upload attachments to H-1751; got the
> mesage:
>
> Exception trying to establish attachment directory. Check that the
> application server and JIRA have permissions to write to it:
> com.atlassian.jira.web.util.AttachmentException: Cannot write to
attachment
> directory. Check that the application server and JIRA have permissions
to
> write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751
> Are
> there any problems with attachment directory?
> I'll make another try later.

I suspect this is the way JIRA suggest that you file a new issue,
so that issue has just one contributor / patch submitter.

I've seen that message when trying to attach files to issue filed
by someone else. Attaching to one's own issues works okay.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [classlib][util.prefs] Implementation should be compatible with RI

[Elena Semukhina]

I prepared the patch for the test and a sample patch for implementation
which enables the test passing on IBM VME. As I'm not an expert in
util.prefs, I'd like someone to review the patch and add a warning message.

Unfortunately I did not manage to upload attachments to H-1751; got the
mesage:

Exception trying to establish attachment directory. Check that the
application server and JIRA have permissions to write to it:
com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment
directory. Check that the application server and JIRA have permissions to
write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751 Are
there any problems with attachment directory?
I'll make another try later.



On 10/12/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:


Can you provide a patch for the test case that correctly asserts the
specification's contract and passes on the RI? This may help for
someone to provide a fix for the issue.

-Nathan

On 10/11/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest fails on
some
> machines when there are restrictions in access to system registry.
> https://issues.apache.org/jira/browse/HARMONY-1751 describes the issue.
It
> looks like Harmony implementation does not follow spec for
> Preferences.systemNodeForPackage(). Besides, the test is incorrect as
well
> because it does not expect java.util.prefs.BackingStoreException on
> Preferences.childrenNames() and fails on RI.
>
> Could anyone look into the issue?
>
> --
> Thanks,
> Elena
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

[classlib][util.prefs] Implementation should be compatible with RI

[Elena Semukhina]

Hi all,

org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest fails on some
machines when there are restrictions in access to system registry.
https://issues.apache.org/jira/browse/HARMONY-1751 describes the issue. It
looks like Harmony implementation does not follow spec for
Preferences.systemNodeForPackage(). Besides, the test is incorrect as well
because it does not expect java.util.prefs.BackingStoreException on
Preferences.childrenNames() and fails on RI.

Could anyone look into the issue?

--
Thanks,
Elena

[drlvm][unit tests] the goal is to achieve 100% pass rate

[Elena Semukhina]

Hello all,

I think that the goal of running classlib unit tests on DRLVM with 100% pass
rate could be worth to achieve. Actually today we have 99% (without
awt/swing) but still have about 30 failures/errors. Most of them have been
evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki
which lists those JIRA issues:

http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM

Are there any volunteers to help with DRLVM bugs fixing?

Thanks,
Elena

Re: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582

[Elena Semukhina]

Nikolay,

I thought that it was the problem in the test so I volunteered to fix it but
now I see that this is hythread issue so please fix it asap!

BTW, I see a lot of new classlib tests failures related to this bug. I
updated H-1789 with instructions how to reproduce this.


On 10/10/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:


Elena,
thanks for the help, the problem discovered by ThreadTest explained in
HARMONY-1789.
Are you going to fix the issue or investigate test failures?

Thank you.
  Nik.

On 10/10/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> I'm going to take care of j.l.ThreadTest.
>
> On 10/10/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> >
> > I have finished running release build on WinXP, and I have following
> > tests results:
> > c_unit tests passed;
> > smoke tests passed, but I have excluded gc.Los;
> > kernel tests works with the 98.96 % success rate on all, jitrino.jet,
> > opt and interpreter. Failing tests are:
> > j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest
> >
> > Thank you.
> > Nik.
> >
> >
> > On 10/9/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> > > I'm running debug build on WinXP, and I have following results so
far:
> > > c_unit tests passed;
> > > smoke tests passed except gc.Los which hangs as usual;
> > > kernel tests works with the following success rates:
> > > Jet : 98.96%
> > > Opt: 99.15%
> > > Int  : still running
> > >
> > > Thank you.
> > > Nik.
> > >
> > > On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > > Ok - I just committed 1582.  Lets build on it... can someone test
on
> > > > winxp?  I'll get to it in a bit, but would be happy to know sooner
> > than
> > > > later.
> > > >
> > > > Evgueni Brevnov wrote:
> > > > > Ok, I see. Then it should be TM problem right?
> > > > >
> > > > > On 10/9/06, Nikolay Kuznetsov <[EMAIL PROTECTED]>
wrote:
> > > > >> Evgueni,
> > > > >>
> > > > >> according to the spec the thread wait method should throw
> > interrupted
> > > > >> exception even if it was interrupted before call.
> > > > >>
> > > > >> citing from the Object.wait method specification:
> > > > >> "Throws:
> > > > >>
> > > > >> InterruptedException - if another thread interrupted the
current
> > > > >> thread before or while the current thread was waiting for a
> > > > >> notification. The interrupted status of the current thread is
> > cleared
> > > > >> when this exception is thrown."
> > > > >>
> > > > >> The same applicable, to the sleep and join methods.
> > > > >>
> > > > >> Thank you.
> > > > >>   Nik.
> > > > >>
> > > > >> On 10/9/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
> > > > >> > Hi,
> > > > >> >
> > > > >> > While testing HARMONY-1582 (invocation api) it turned out
that
> > one
> > > > >> > kernel test starts to fail with the following message:
> > > > >> >
> > > > >> > There were 3 failures:
> > > > >> > 1)
> > > > >> testInterrupt_Joining(java.lang.ThreadTest
> > )junit.framework.AssertionFailed
> > > > >>
> > > > >> > Error: joining thread has not received the
InterruptedException
> > > > >> > at
> > > > >> java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java
:1367)
> > > > >> > at java.lang.reflect.VMReflection.invokeMethod(Native
> > Method)
> > > > >> > 2)
> > > > >> testInterrupt_Sleeping(java.lang.ThreadTest
> > )junit.framework.AssertionFaile
> > > > >>
> > > > >> > dError: sleeping thread has not received the
InterruptedException
> > > > >> > at
> > > > >> java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java
:1390)
> > > > >> > at java.lang.reflect.VMReflection.invokeMethod(Native
> > Method)
> > > > >> > 3)
> > > > >> testInterrupt_Waiting(java.lang.ThreadTest
> > )junit.framework.AssertionFailed
> > > > >>
> > > >

Re: [classlib][test] Failure in swing test

[Elena Semukhina]

I see some fairures on Windows of javax.swing.filechooser.FileSystemViewTest,
e.g:

testGetSystemDisplayName Failure Test interrupted due timeout

Besides, tests asked me to insert disk to drive A:

On 10/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:



On 10 October 2006 at 8:53, Mark Hindess <[EMAIL PROTECTED]>
wrote:
>
> On 10 October 2006 at 14:19, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote:
> > Please wait.
>
> Too late.  Back out r454633 if you wish.
>
> I asked people to test this and report back last week.  No one said
> don't do it.  And lots of people said '+1'.
>
> > what are you going to do with linux?
>
> I've talked about this on and off for several months, but ...
>
> Libraries such as libpng, libjpeg, and liblcms are stable and rarely
> change significantly between distributions, so we should use the
> versions provided by OS vendors.
>
> AFAIK, no one seems to have figured out which packages are required on
> any non-debian based distribution.  I asked for this information months
> ago, but I assumed that no one was using other distributions or that
> they simply thought it easier to build it themselves.
>
> I am in the process of creating chroot/vmware/qemu images of recent
> versions of both Red Hat and SuSE in order to derive the correct
> instructions.
>
> The reason I believe that using system versions is the right way to
> go is that I believe we should be using shared libraries for these
> dependencies and not statically linking them.
>
> Of course, some libraries are developing too quickly for distributions
> to keep up so we will end up distributing them - ICU for instance.
>
> Everyone seems happy enough with the solution on Debian-based distros
> and it should be just as trivial to resolve the problem on RedHat and
> SuSE.  It just takes someone with those distributions to figure out
> the appropriate packages/commands.

For instance, I'm reliably informed that:

yast --install libpng-devel libjpeg-devel liblcms-devel

works on SLES 10 if you have a yast source configured correctly.

The RHEL4 equivalent probably involves up2date.

I think FC5 has yum so that should be a similar "yum install" command.
(I think this means that RHEL5 when it arrives while have yum too.)

Regards,
Mark.

> > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>:
> > >
> > > On 9 October 2006 at 16:02, Tim Ellison <[EMAIL PROTECTED]>
wrote:
> > > > Works for me too now ...
> > > >
> > > > Unless anyone objects I suggest that we make the 'with.awt.swing'
> > > > default behavior (and we'll see the failure if it happens again).
> > >
> > > Excellent.  I'll dump the property unless anyone else beats me
> > > to it.
> > >
> > > -Mark.
> > >
> > > > Regards,
> > > > Tim
> > > >
> > > > Oleg Khaschansky wrote:
> > > > > Tim,
> > > > >
> > > > > I can't see this failure at r454268. Anyone else see it? Maybe
rebuil
> d
> > > > > will help?
> > > > >
> > > > > I also looked into SpinnerDateModelTest source and it doesn't
seems t
> o
> > > > > me that it could be related to the TransferHandler.
> > > > >
> > > > > --
> > > > > Oleg
> > > > >
> > > > > On 10/9/06, Oleg Khaschansky <[EMAIL PROTECTED]>
wrote:
> > > > >> I will take a look at this.
> > > > >>
> > > > >> On 10/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > > > >> > I see a failure on IA32 Win XP tests at r454168 (after
applying th
> e
> > > > >> > TransferHandler patch).
> > > > >> >
> > > > >> > The walkback is:
> > > > >> >
> > > > >> >  junit.framework.AssertionFailedError: expected:<0> but
was:<7> at
> > > > >> >
> > > > >> javax.swing.SpinnerDateModelTest.testSpinnerDateModel
(SpinnerDateMod
> el
> > Test
> > > > .java:59)
> > > > >>
> > > > >> > at
> > > > >> >
> > > > >> java.lang.reflect.AccessibleObject.invokeV(
AccessibleObject.java:25)
>  a
> > t
> > > > >> >
> > > > >> javax.swing.BasicSwingTestCase.runBareSuper(
BasicSwingTestCase.java:
> 11
> > 5)
> > > > >> > at
> > > > >> >
> > > > >> javax.swing.BasicSwingTestCase.runBareImpl(
BasicSwingTestCase.java:1
> 20
> > )
> > > > >> at
> > > > >> >  javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java
:133)
>  a
> > t
> > > > >> >  java.lang.Thread.run(Thread.java:872)
> > > > >> >
> > > > >> > I'll take a look later unless somebody picks it up.
> > > > >> >
> > > > >> > Regards,
> > > > >> > Tim
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Tim Ellison ([EMAIL PROTECTED])
> > > > >> > IBM Java technology centre, UK.
> > > > >> >
> > > > >> >
--
> --
> > -
> > > > >> > Terms of use :
http://incubator.apache.org/harmony/mailing.html
> > > > >> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> rg
> > > > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> .o
> > rg
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > > >
-
> > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > > To unsubscribe, e-mail:
[EMAIL

Re: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582

[Elena Semukhina]

I'm going to take care of j.l.ThreadTest.

On 10/10/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:


I have finished running release build on WinXP, and I have following
tests results:
c_unit tests passed;
smoke tests passed, but I have excluded gc.Los;
kernel tests works with the 98.96 % success rate on all, jitrino.jet,
opt and interpreter. Failing tests are:
j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest

Thank you.
Nik.


On 10/9/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> I'm running debug build on WinXP, and I have following results so far:
> c_unit tests passed;
> smoke tests passed except gc.Los which hangs as usual;
> kernel tests works with the following success rates:
> Jet : 98.96%
> Opt: 99.15%
> Int  : still running
>
> Thank you.
> Nik.
>
> On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > Ok - I just committed 1582.  Lets build on it... can someone test on
> > winxp?  I'll get to it in a bit, but would be happy to know sooner
than
> > later.
> >
> > Evgueni Brevnov wrote:
> > > Ok, I see. Then it should be TM problem right?
> > >
> > > On 10/9/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> > >> Evgueni,
> > >>
> > >> according to the spec the thread wait method should throw
interrupted
> > >> exception even if it was interrupted before call.
> > >>
> > >> citing from the Object.wait method specification:
> > >> "Throws:
> > >>
> > >> InterruptedException - if another thread interrupted the current
> > >> thread before or while the current thread was waiting for a
> > >> notification. The interrupted status of the current thread is
cleared
> > >> when this exception is thrown."
> > >>
> > >> The same applicable, to the sleep and join methods.
> > >>
> > >> Thank you.
> > >>   Nik.
> > >>
> > >> On 10/9/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
> > >> > Hi,
> > >> >
> > >> > While testing HARMONY-1582 (invocation api) it turned out that
one
> > >> > kernel test starts to fail with the following message:
> > >> >
> > >> > There were 3 failures:
> > >> > 1)
> > >> testInterrupt_Joining(java.lang.ThreadTest
)junit.framework.AssertionFailed
> > >>
> > >> > Error: joining thread has not received the InterruptedException
> > >> > at
> > >> java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367)
> > >> > at java.lang.reflect.VMReflection.invokeMethod(Native
Method)
> > >> > 2)
> > >> testInterrupt_Sleeping(java.lang.ThreadTest
)junit.framework.AssertionFaile
> > >>
> > >> > dError: sleeping thread has not received the InterruptedException
> > >> > at
> > >> java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390)
> > >> > at java.lang.reflect.VMReflection.invokeMethod(Native
Method)
> > >> > 3)
> > >> testInterrupt_Waiting(java.lang.ThreadTest
)junit.framework.AssertionFailed
> > >>
> > >> > Error: waiting thread has not received the InterruptedException
> > >> > at
> > >> java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413)
> > >> > at java.lang.reflect.VMReflection.invokeMethod(Native
Method)
> > >> >
> > >> > FAILURES!!!
> > >> > Tests run: 89,  Failures: 3,  Errors: 0
> > >> >
> > >> > Short investigation shows that test is invalid. Specifically main
> > >> > thread interrupts another thread and expects InterruptedException
will
> > >> > be thrown while interruptable thread doesn't get to
> > >> > joining/sleeping/waiting state yet.
> > >> >
> > >> > Could somebody fix that
> > >> >
> > >> > Thanks
> > >> > Evgueni.
> > >> >
> > >> >
-
> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> > >> >
> > >> >
> > >>
> > >>
-
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > >> For additional commands, e-mail:
[EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
-
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [classlib] build problem.... I'm forgetting something obvious...

[Elena Semukhina]

On 10/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


still on that new machine.

classlib builds fine, but "ant test" results in it appearing to be very,
very confused when trying to compile, with the first module,
accessibility.

It can't find things like "BasicSwingTestCase", although I can confirm
that it was build in test_support...

I figure I forgot something obvious...



Yes, you forgot to copy junit.jar to ant's lib directory.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

[drlvm] passing extra options to vm fails on Widows XP

[Elena Semukhina]

I failed to run any application with -Xem:jet (and -Xem:opt as well) set in
harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I
even copied that file from Windows 2003 machine to XP machine but this did
not help.

"java Test" gives me the following:

An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=004020DF
ContextFlags=0001003f
Handler1=00401010
Handler2=11105CE0
InaccessibleAddress=0550
EDI=
ESI=001531F0
EAX=
EBX=
ECX=004044F4
EDX=4C25
EIP=004020DF
ESP=0013F970
EBP=0550
Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe
Module_base_address=0040
Offset_in_DLL=20df

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.


--
Thanks,
Elena

Re: [drlvm][jet] Could you please look into HARMONY-1678?

[Elena Semukhina]

Egor,

please take a look at HARMONY-1724 as well. This is also JET related
classlib test failure.


On 06 Oct 2006 11:59:42 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:


On the 0x1FA day of Apache Harmony Alexei A. Fedotov wrote:
> Egor, Alex,
>
>
>
> Please, could you volunteer to look into
> http://issues.apache.org/jira/browse/HARMONY-1678? Alexey Varlamov found
> it while investigating security unit tests and reported it as
> JET-specific. This would be very kind of you to find a cure.

I am taking a look.

P.S. you are promoting a low-priority bug while there are a lot of
critical crashes flying around. Is it marked as "Minor" by mistake?

--
Egor Pasko, Intel Managed Runtime Division


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

[j9][testing] some classlib unit tests fail

[Elena Semukhina]

Hello, all,

AFAIK, "ant test" should give 100% pass rate on j9 but I have 5 failures
which seem to be dependent on environment.
I've uploaded the results at
http://harmonytest.org/testapp.do?method=showrun&id=9&perPage=100&page=1&name=&result=0&jira=0

There are also two JIRA issues detailing this:
HARMONY-1664 and
HARMONY-1674 

Can anyone help in analyzing the problem?

--
Thanks,
Elena

Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code

[Elena Semukhina]

This issue is accompanied now with similar crash on Windows (interpreter):
[echo] RUNNING : java.lang.RuntimeTest

   [junit] This application has requested the Runtime to terminate it in an
unu
sual way.
   [junit] Please contact the application's support team for more
information.
   [junit] ...VM Crashed!
   [junit] Windows reported exception: ACCESS_VIOLATION
   [junit] Registers:
   [junit] EAX: 0x, EBX: 0x026084f8, ECX: 0x0f7db83a,
EDX=0x000
0
   [junit] ESI: 0x0013d180, EDI: 0x1401, ESP: 0x0013d16c,
EBP=0x0013d21
8
   [junit] EIP: 0x015f6085
   [junit] Assertion failed: !interpreter_enabled(), file
C:\users\esemukhi\svn
\drlvm\trunk\vm\port\src\lil\ia32\pim\stack_iterator_ia32.cpp, line 212

   [junit] This application has requested the Runtime to terminate it in an
unu
sual way.
   [junit] Please contact the application's support team for more
information.
   [junit] Test java.lang.RuntimeTest FAILED


On 10/2/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:


2006/10/2, Alexey Varlamov <[EMAIL PROTECTED]>:
> Trace logging gives some more details:
> 
> GC enumeration in interpreter stack:
>
> 0x0x413ee828 referenced from root = 0x0x52721d4c info = 0
> 0x0x413ee828 info = 0
> 0x0x413ee828 is java/lang/Class
> move 0x0x413ee828 to 0x0x41253d24 info = 1
> 0x(nil) referenced from object = 0x0x41253d24
> 0x(nil) referenced from object = 0x0x41253d24
> 0x(nil) referenced from object = 0x0x41253d24
>  [THIS]: java/lang/Class
> [METHOD ]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I
> 0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576
> 0x0x414e9530 info = -2147480576
> 0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock
> move 0x0x414e9530 to 0x0x41253d44 info = -2147480575
>  [THIS]: java/lang/FinalizerThread$FinalizerWorkLock
> [METHOD 4 2]: java/lang/Object.wait()V
>  Stack[0]
> NPE or SOE detected at 0x4114fe18
> ---

I fixed endless looping in HARMONY-1653. And now we need to understand
why the SIGSEGV occurs. Is it corrupted stack or smth else?
Ivan, could you please look into this?

--
Alexey

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm][thread] Thread.currentThread() is not alive anymore :(

[Elena Semukhina]

This issue is fixed with HARMONY-1582 patch as well.

On 9/28/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:


Fixed, patch submitted to JIRA. Thread constructor used to initialize
main thread simply didn't set alive status. This patch also corrects
main thread's name and sets context class loader to SystemClassLoader.

Thank you.
  Nik.

On 9/22/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> Kernel test ThreadTest fails due to Thread.currentThread().isAlive()
returns
> false now.
> I've created a JIRA issue for this problem.
> https://issues.apache.org/jira/browse/HARMONY-1537
>
> Does anyone want to study the issue and submit a patch for it?
>
> --
> Thanks,
> Elena
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm] current tests - can we focus on getting everything to pass?

[Elena Semukhina]

On 28 Sep 2006 18:25:58 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:


On the 0x1F2 day of Apache Harmony Alexey Varlamov wrote:
> 28 Sep 2006 17:50:57 +0700, Egor Pasko <[EMAIL PROTECTED]>:
> > On the 0x1F2 day of Apache Harmony Elena Semukhina wrote:
> > > On 9/28/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Apparently there are some threading issues, which affect almost
all
> > > > suites (except may be smoke tests). I observe quite many sporadic
> > > > crashes in c-unit, kernel and classlib tests. For example, the
> > > > following assert fails often:
> > > > drlvm/vm/thread/src/thread_native_suspend.c:351:
> > > > hythread_set_safepoint_callback: Assertion `status == (0)' failed.
> > > > Another incomprehensible error is described in HARMONY-1614.
> > > > These defects most probably point to races in TM or VM internals,
and
> > > > are hard enough to insulate and root-cause.
> > > >
> > > > Aside from that, there are "known" stable failures, like kernel
> > > > ThreadTest and ClassLoaderTest, or classlib's
> > >
> > >
> > > ThreadTest is a kind of "always failing test" unfortunately. Now its
failure
> > > is related to launcher related issue mentioned in another thread as
well as
> > > the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582
patch.
> > > On the other hand, HARMONY-1582 reports that ThreadTest fails
showing up new
> > > problems possibly related to H-1519 patch. So ThreadTest is very
helpful in
> > > catching regressions and should be paid a special attention to each
time it
> > > fails :)
> > >
> > > As for general statistics of kernel test failures, ThreadTest fails
now on
> > > all platforms in all modes (jet, opt, int) and ClassLoaderTest and
> > > ClassAnnotationTest fail on opt (win, linux), which is under Egor's
> > > investigation.
> >
> > ClassLoaderTest, to be precise..
> > ClassAnnotatationsTest passes for me on linux
>
> It crashes sometimes (not very often) on OPT with the same trace as
> ClassLoaderTest which actually tells nothing...

hmm.. ten times in a row it passed for me. If you reproduced the
failure with memopt OFF, that would be valuable. If you cannot
reproduce with memopt OFF, knowing that would be valuable too :)



With memopt OFF, both tests pass on both linux and windows.

--

Egor Pasko, Intel Managed Runtime Division


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code

[Elena Semukhina]

The issue has gone away for me too, false alarm possibly...

Elena

On 9/28/06, Pavel Rebriy <[EMAIL PROTECTED]> wrote:


I've just repeated kernel.test run today several times on fresh build, and
tests pass.
It's a very stange crash. Execute JIT stack iterator in interpreter mode..
It's outlandishly.

On 28/09/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> I do not observe this crash - I ran kernel tests yesterday and today
> several times, no crashes on interpreter on Linux IA32...
>
> 2006/9/28, Gregory Shimansky <[EMAIL PROTECTED]>:
> > On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote:
> > >  :)
> > >
> > > Is there an easy fix, or do we rollback?
> >
> > Interpreter is meant for the development for the most part. I think it
> is not
> > critical if it doesn't work for a short time. It is not used by most
of
> the
> > community anyway because they don't specify -Xint option to run the
> programs.
> >
> > I hope the patch submitter will respond with a fix soon enough.
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Best regards,
Pavel Rebriy





--
Thanks,
Elena

Re: [drlvm] current tests - can we focus on getting everything to pass?

[Elena Semukhina]

On 9/28/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:


Apparently there are some threading issues, which affect almost all
suites (except may be smoke tests). I observe quite many sporadic
crashes in c-unit, kernel and classlib tests. For example, the
following assert fails often:
drlvm/vm/thread/src/thread_native_suspend.c:351:
hythread_set_safepoint_callback: Assertion `status == (0)' failed.
Another incomprehensible error is described in HARMONY-1614.
These defects most probably point to races in TM or VM internals, and
are hard enough to insulate and root-cause.

Aside from that, there are "known" stable failures, like kernel
ThreadTest and ClassLoaderTest, or classlib's



ThreadTest is a kind of "always failing test" unfortunately. Now its failure
is related to launcher related issue mentioned in another thread as well as
the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch.
On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new
problems possibly related to H-1519 patch. So ThreadTest is very helpful in
catching regressions and should be paid a special attention to each time it
fails :)

As for general statistics of kernel test failures, ThreadTest fails now on
all platforms in all modes (jet, opt, int) and ClassLoaderTest and
ClassAnnotationTest fail on opt (win, linux), which is under Egor's
investigation.

Thanks,
Elena

org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and

org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are
good candidates to fix first - especially Thread related - maybe this
would help to get closer to more subtle defects.


28 Sep 2006 14:47:27 +0700, Egor Pasko <[EMAIL PROTECTED]>:
> On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote:
> > Right now, we have lots of tests that are skipped in smoke tests, and
> > some that fail in kernel, and I believe that we're still failing the
> > classlib test suite.
> >
> > We should drive this to goodness and health.  How shall we start?  :)
>
> I am working on the ClassLoaderTest :)
> "memopt" optimization pass makes it fail, it even removes some
> array-bounds-checks (surprize, surprize), which looks like, ehm,
> unfair. For now I could not reduce the test to a small one. On small
> pieces of code "memopt" works less dangerously.
>
> Disabling "memopt" helps, but that would drop performance down. You
> can disable it temporarily if stability is very critical. Just edit
> the opt.emconf file (and server.emconf, etc.)
>
> --
> Egor Pasko, Intel Managed Runtime Division
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code

[Elena Semukhina]

I just wondered what changed after yesterday, rolled back HARMONY-1559 patch
and so discovered cause-effect relation.
I can say nothing about the fix, we should ask the patch submitter :(


On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


 :)

Is there an easy fix, or do we rollback?

geir

On Sep 27, 2006, at 8:32 AM, Elena Semukhina wrote:

> Hi all,
>
> after HARMONY-1559 patch has been committed, kernel unit test
> RuntimeTest
> started to fail on linux in the interpreter mode.
> It loops with the message
>
>[junit] SIGABRT in VM code.
>[junit] java:
> /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/
> ia32/pim/stack_iterator_ia32.cpp:211:
> StackIterator* si_create_from_native(): Assertion `!
> interpreter_enabled()'
> failed.
>
> and fails on timeout.
> I rolled back the changes and test passed.
>
> --
> Thanks,
> Elena





--
Thanks,
Elena

[drlvm] HARMONY-1559 patch causes SIGABRT in VM code

[Elena Semukhina]

Hi all,

after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest
started to fail on linux in the interpreter mode.
It loops with the message

   [junit] SIGABRT in VM code.
   [junit] java:
/nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:211:
StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()'
failed.

and fails on timeout.
I rolled back the changes and test passed.

--
Thanks,
Elena

Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448

[Elena Semukhina]

On 9/26/06, Spark Shen <[EMAIL PROTECTED]> wrote:


Geir Magnusson Jr. 写道:
>
> On Sep 21, 2006, at 10:07 PM, Paulex Yang wrote:
>
>> Geir Magnusson Jr. wrote:
>>> Do you think this is a drlvm issue or a classlib issue?
>> I guess it is an integration issue, i.e., ICU4J's UCharacter needs to
>> load some resources for initialization, while at that time on DRLVM,
>> some necessary kernel classes haven't been inited, so that the
>> UCharacter cannot load these properties sucessfully and leave them to
>> null. I'll roll back the patch for Character temporarily if no one
>> objects, and will look inside later(I need to checkout ICU4J's source
>> at first ...).
>
> Fascinating. What are we missing in DRLVM?
After a long investigation, I thought the jar package icu4j_3.4.4 was
not loaded by DRLVM. And I modified
build\make\targets\kernel.test.xml:
Line 204: 
then no more NPE will be thrown out.

I want to reproduce this bug on r449972, but as another thread [[drlvm]
none of kernel tests passed for the recent sources] depicts.
So I could not verify whether this is a work around. Could anyone gives
a hint?



Kernel tests running issue has been solved after the patch from HARMONY-1457
has been applied (please see [drlvm] my latest round of patches broke
something]). Please do svn update for drlvm and run
build.bat update
build.bat
build.bat test

Best regards

>
> geir
>
>>>
>>> geir
>>>
>>> On Sep 21, 2006, at 1:07 AM, Vladimir Gorr wrote:
>>>
 NPE is thrown for all kernel tests when testing is run on Windows at
 revision 448448:

 build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test

 ...
 [echo] RUNNING : java.lang.Class1_5Test
 [junit] java.lang.NullPointerException
 [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java
 :6073)

 [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974)
 [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java
 :3162)
 [junit] at java.lang.Character.isWhitespace(Character.java:3091)
 [junit] at java.lang.Character.isWhitespace(Character.java:3078)
 [junit] at java.util.Properties.load(Properties.java:378)
 [junit] at java.util.PropertyResourceBundle.(
 PropertyResourceBundle.java:44)
 snipped

 Does anybody observe this issue? As for Linux all works fine.

 Thanks,
 Vladimir.
>>>
>>>
>>> -
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> --Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Spark Shen
China Software Development Lab, IBM


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

[drlvm][thread] Thread.currentThread() is not alive anymore :(

[Elena Semukhina]

Kernel test ThreadTest fails due to Thread.currentThread().isAlive() returns
false now.
I've created a JIRA issue for this problem.
https://issues.apache.org/jira/browse/HARMONY-1537

Does anyone want to study the issue and submit a patch for it?

--
Thanks,
Elena

Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))

[Elena Semukhina]

On 9/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:



On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote:

> On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>> On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >
>> > Looking at ThreadTest failures I see that all 1421-related failures
>> > disappear. But there are 3 new failures which I've never seen
>> before.
>> Two
>> > of
>> > them actually relate to "using the launcher" problems,
>>
>>
>> Is it possible to give more details about this or to file new JIRA
>> issue?
>
>
> These tests reveal that the main thread's name and thread group
> hierarchy
> have been changed with the launcher implementation.

But that will be the case anytime in general right?  You can't assume
what is creating and invoking the VM.



You are right in general but in particular we are testing drlvm now and it
is desirable that our tests pass on some other VMs (Sun, BEA, IBM) as well
and nothing more for today :)
The test that checks the name of the main thread is not as useless as it
looks at first glance. At least, it helps to reveal that something has been
changed and stimulates to look thouroughly into that :)

So looking thouroughly into the changes I discovered that the thread group
hierarchy has been changed. Previously we had the "system" thread group at
the top (which parent is null) containing the subgroup "main" where the main
thread was created. This hierarchy is not specified explicitly but is
assumed. Otherwise any thread created by main thread in its thread group
becomes a "system thread", which is not our intention but drlvm works this
way now. E.g. the following test passes on the above mentioned VMs and fails
on drlvm now with AccessControlException at t.checkAccess(), which is
undoubtely unexpected behavior. The good news is that Evgueni is going to
restore the "main" thread group.

public class ThreadSecurityManager {
   public static void main(String[] args) {
   Thread t = new Thread();
   if (t.getThreadGroup().getParent() == null) {
   System.out.println("created in the system thread group");
   }
   System.setSecurityManager(new SecurityManager());
   t.checkAccess();
   System.out.println("Passed");
   }
}
Thanks,
Elena



> As Evgueni said that he
> worked on Invocation API [1], I asked him to run these tests in his
> environment and they passed.
> So we should wait until his changes are approved and committed.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
> 200609.mbox/%
> [EMAIL PROTECTED]
>
> Thanks,
> Elena
>
> Thanks,
>> Vladimir.
>>
>> but the third one deserves a special investigation.
>> >
>> > The problem is that Thread.currentThread().isAlive() returns
>> false now.
>> > Can
>> > anyone comment on this?
>> >
>> > Thanks,
>> > Elena
>> >
>> > On 9/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> > >
>> > > I'm not paying much attention to the kernel tests these days
>> while we
>> > > sort out the main problems.
>> > >
>> > > I do think that once we sort out the "using the launcher"
>> problems,
>> > > and get the patch backlog applied, we really should go after
>> all of
>> > > these broken tests
>> > >
>> > > We also need to refractor the test framework so including/
>> excluding a
>> > > test doesn't require changing the test source code...
>> > >
>> > > geir
>> > >
>> > > On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote:
>> > >
>> > > > On 9/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> > > >>
>> > > >> patch applied, JIRA closed
>> > > >
>> > > >
>> > > > Good.  I was just about to suggest the very same thing.  I
>> applied
>> > > > both of
>> > > > the 1421 patches and a substantial number of tests now run on
>> > > > windows.  At
>> > > > this time I see only the below test failures.  I commented out
>> > > > gc.LOS test
>> > > > because it still hangs.
>> > > >
>> > > >
>> > > >[junit] Test java.lang.ThreadGroupTest FAILED
>> > > >[junit] Test java.lang.ThreadGroupTest FAILED
>> > > > [echo] FAILED on reference JRE 
>> > > >[junit] Test java.

Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))

[Elena Semukhina]

On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:


On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> Looking at ThreadTest failures I see that all 1421-related failures
> disappear. But there are 3 new failures which I've never seen before.
Two
> of
> them actually relate to "using the launcher" problems,


Is it possible to give more details about this or to file new JIRA issue?



These tests reveal that the main thread's name and thread group hierarchy
have been changed with the launcher implementation. As Evgueni said that he
worked on Invocation API [1], I asked him to run these tests in his
environment and they passed.
So we should wait until his changes are approved and committed.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
 PROTECTED]

Thanks,
Elena

Thanks,

Vladimir.

but the third one deserves a special investigation.
>
> The problem is that Thread.currentThread().isAlive() returns false now.
> Can
> anyone comment on this?
>
> Thanks,
> Elena
>
> On 9/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > I'm not paying much attention to the kernel tests these days while we
> > sort out the main problems.
> >
> > I do think that once we sort out the "using the launcher" problems,
> > and get the patch backlog applied, we really should go after all of
> > these broken tests
> >
> > We also need to refractor the test framework so including/excluding a
> > test doesn't require changing the test source code...
> >
> > geir
> >
> > On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote:
> >
> > > On 9/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > >>
> > >> patch applied, JIRA closed
> > >
> > >
> > > Good.  I was just about to suggest the very same thing.  I applied
> > > both of
> > > the 1421 patches and a substantial number of tests now run on
> > > windows.  At
> > > this time I see only the below test failures.  I commented out
> > > gc.LOS test
> > > because it still hangs.
> > >
> > >
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ThreadTest FAILED
> > >[junit] Test java.lang.ThreadTest FAILED
> > > [echo] FAILED on reference JRE 
> > > [echo] Kernel tests FAILED using jitrino.jet. Please find the
> > > detailed
> > > resu
> > >
> > >[junit] Test java.lang.ClassAnnotationsTest FAILED
> > >[junit] Test java.lang.ClassAnnotationsTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ClassLoaderTest FAILED
> > >[junit] Test java.lang.ClassLoaderTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ThreadTest FAILED
> > >[junit] Test java.lang.ThreadTest FAILED
> > > [echo] FAILED on reference JRE 
> > > [echo] Kernel tests FAILED using jitrino.opt. Please find the
> > > detailed
> > > resu
> > >
> > >[junit] Test java.lang.ClassGenericsTest FAILED (timeout)
> > >[junit] Test java.lang.ClassGenericsTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > >[junit] Test java.lang.ThreadGroupTest FAILED
> > > [echo] FAILED on reference JRE 
> > >[junit] Test java.lang.ThreadTest FAILED
> > >[junit] Test java.lang.ThreadTest FAILED
> > > [echo] FAILED on reference JRE 
> > > [echo] Kernel tests FAILED using interpreter. Please find the
> > > detailed
> > > resu
> > >
> > > geir
> > >
> > >
> > > --
> > > Weldon Washburn
> > > Intel Middleware Products Division
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Thanks,
> Elena
>
>





--
Thanks,
Elena

Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))

[Elena Semukhina]

Looking at ThreadTest failures I see that all 1421-related failures
disappear. But there are 3 new failures which I've never seen before. Two of
them actually relate to "using the launcher" problems, but the third one
deserves a special investigation.

The problem is that Thread.currentThread().isAlive() returns false now. Can
anyone comment on this?

Thanks,
Elena

On 9/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


I'm not paying much attention to the kernel tests these days while we
sort out the main problems.

I do think that once we sort out the "using the launcher" problems,
and get the patch backlog applied, we really should go after all of
these broken tests

We also need to refractor the test framework so including/excluding a
test doesn't require changing the test source code...

geir

On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote:

> On 9/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> patch applied, JIRA closed
>
>
> Good.  I was just about to suggest the very same thing.  I applied
> both of
> the 1421 patches and a substantial number of tests now run on
> windows.  At
> this time I see only the below test failures.  I commented out
> gc.LOS test
> because it still hangs.
>
>
>[junit] Test java.lang.ThreadGroupTest FAILED
>[junit] Test java.lang.ThreadGroupTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ThreadTest FAILED
>[junit] Test java.lang.ThreadTest FAILED
> [echo] FAILED on reference JRE 
> [echo] Kernel tests FAILED using jitrino.jet. Please find the
> detailed
> resu
>
>[junit] Test java.lang.ClassAnnotationsTest FAILED
>[junit] Test java.lang.ClassAnnotationsTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ClassLoaderTest FAILED
>[junit] Test java.lang.ClassLoaderTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ThreadGroupTest FAILED
>[junit] Test java.lang.ThreadGroupTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ThreadTest FAILED
>[junit] Test java.lang.ThreadTest FAILED
> [echo] FAILED on reference JRE 
> [echo] Kernel tests FAILED using jitrino.opt. Please find the
> detailed
> resu
>
>[junit] Test java.lang.ClassGenericsTest FAILED (timeout)
>[junit] Test java.lang.ClassGenericsTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ThreadGroupTest FAILED
>[junit] Test java.lang.ThreadGroupTest FAILED
> [echo] FAILED on reference JRE 
>[junit] Test java.lang.ThreadTest FAILED
>[junit] Test java.lang.ThreadTest FAILED
> [echo] FAILED on reference JRE 
> [echo] Kernel tests FAILED using interpreter. Please find the
> detailed
> resu
>
> geir
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks,
Elena

Re: [drlvm] Need help debugging

[Elena Semukhina]

I'll fix it with great pleasure!

BTW, I managed to run Eclipse 3.2 even with that buggy code. But running
java -jar fails.

Elena

On 9/14/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:


Ha-ha that code was buggy anyway :-) As I've already said we do need
filter Thread.runImpl frames for java threads created by calling
Thread.start method. Elena, you've fixed that code once, probably, you
wish to fix it once again? :-)

Thank you
Evgueni

On 9/14/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> Oops, I haven't waited for Evgueni's message. The fix suggested in
> HARMONY-1431 does not imply the launcher implementation...
>
> Thanks,
> Elena
>
> On 9/14/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> >
> >  Actually, the code should be fixed rather than commented out in the
> > following way:
> >
> > //--size;
> >
> > // skip the VMStart$MainThread.runImpl() if it exists from the
bottom
> >
> > // of the stack along with 2 reflection frames used to invoke
method
> > main
> >
> > static String* starter_String =
> > genv->string_pool.lookup("java/lang/VMStart$MainThread");
> > Method_Handle method = frames[size - 1].method;
> > assert(method);
> >
> > if (!strcmp(method_get_name(method), "runImpl")
> > && method->get_class()->name == starter_String) {
> > for (; --size;) {
> > method = frames[size - 1].method;
> > assert(method);
> > if ((strstr(method->get_class()->name->bytes,
> > "java/lang/reflect"))
> > == NULL) {
> > break;
> >
> > }
> > }
> > }
> >
> > ASSERT(size >= skip, "Trying to skip " << skip
> > << " frames but there are only "
> > << size << " frames in stack");
> >
> >
> > The fix has been submitted in HARMONY-1431 which depends on
HARMONY-1363.
> >
> > As for Eclipse's silent exit, please try to find what has happened in
the
> > eclipse/configuration/*.log files.
> >
> > Thanks,
> > Elena
> >
> >  On 9/14/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > >
> > > I'd like to understand why this is no longer necessary.
> > >
> > > (Just provide some background for all of us to help start
understanding
> > > the structure and operation of DLRVM)
> > >
> > > geir
> > >
> > >
> > > Vladimir Gorr wrote:
> > > > Probably, you didn't note I've commented this fragment of code
(firts
> > > &
> > > > last
> > > > lines).
> > > > Sorry I didn't mention about this before. After these changes I
could
> > > > sucessfully start the ActiveMQ.
> > > > Before I have the following error:
> > > >
> > > > Assertion failed: size >= skip
> > > > Trying to skip 6 frames but there are only 5 frames in stack
> > > > java:
> > > >
> > >
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
> > >
> > > >
> > > > _jobject*
Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
> > > > _jobject*, _jobject*): Assertion `size >= skip' failed.
> > > > abort_handler()
> > > >
> > > > Thanks,
> > > > Vladimir.
> > > >
> > > > On 9/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> I'm a little skeptical, as I had that change in before you first
> > > tested
> > > >> and found a problem, right?
> > > >>
> > > >> geir
> > > >>
> > > >>
> > > >> Vladimir Gorr wrote:
> > > >> >
> > >
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
> > > >> > ...
> > > >> > * /*
> > > >> > *// skip Thread.runImpl()
> > > >> >size--;
> > > >> >
> > > >> >// skip the VMStart$MainThread if one exits from the bottom
of
> > > the
> > > >> stack
> > > >> >// along with 2 reflection frames used to invoke method main
> > > >> >static String* starter_String =
> > > >> > genv->string_pool.

Re: [drlvm] Need help debugging

[Elena Semukhina]

Oops, I haven't waited for Evgueni's message. The fix suggested in
HARMONY-1431 does not imply the launcher implementation...

Thanks,
Elena

On 9/14/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:


 Actually, the code should be fixed rather than commented out in the
following way:

//--size;

// skip the VMStart$MainThread.runImpl() if it exists from the bottom

// of the stack along with 2 reflection frames used to invoke method
main

static String* starter_String =
genv->string_pool.lookup("java/lang/VMStart$MainThread");
Method_Handle method = frames[size - 1].method;
assert(method);

if (!strcmp(method_get_name(method), "runImpl")
&& method->get_class()->name == starter_String) {
for (; --size;) {
method = frames[size - 1].method;
assert(method);
if ((strstr(method->get_class()->name->bytes,
"java/lang/reflect"))
== NULL) {
break;

}
}
}

ASSERT(size >= skip, "Trying to skip " << skip
<< " frames but there are only "
<< size << " frames in stack");


The fix has been submitted in HARMONY-1431 which depends on HARMONY-1363.

As for Eclipse's silent exit, please try to find what has happened in the
eclipse/configuration/*.log files.

Thanks,
Elena

 On 9/14/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> I'd like to understand why this is no longer necessary.
>
> (Just provide some background for all of us to help start understanding
> the structure and operation of DLRVM)
>
> geir
>
>
> Vladimir Gorr wrote:
> > Probably, you didn't note I've commented this fragment of code (firts
> &
> > last
> > lines).
> > Sorry I didn't mention about this before. After these changes I could
> > sucessfully start the ActiveMQ.
> > Before I have the following error:
> >
> > Assertion failed: size >= skip
> > Trying to skip 6 frames but there are only 5 frames in stack
> > java:
> >
> 
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
>
> >
> > _jobject* Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
> > _jobject*, _jobject*): Assertion `size >= skip' failed.
> > abort_handler()
> >
> > Thanks,
> > Vladimir.
> >
> > On 9/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >>
> >> I'm a little skeptical, as I had that change in before you first
> tested
> >> and found a problem, right?
> >>
> >> geir
> >>
> >>
> >> Vladimir Gorr wrote:
> >> >
> vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
> >> > ...
> >> > * /*
> >> > *// skip Thread.runImpl()
> >> >size--;
> >> >
> >> >// skip the VMStart$MainThread if one exits from the bottom of
> the
> >> stack
> >> >// along with 2 reflection frames used to invoke method main
> >> >static String* starter_String =
> >> > genv->string_pool.lookup("java/lang/VMStart$MainThread");
> >> >Method_Handle method = frames[size].method;
> >> >assert(method);
> >> >// skip only for main application thread
> >> >if (!strcmp(method_get_name(method), "runImpl")
> >> >&& method->get_class()->name == starter_String) {
> >> >int rem = size - skip-1;
> >> >size -= rem < 2 ? rem : 2;
> >> >}
> >> >ASSERT(size >= skip, "Trying to skip " << skip
> >> ><< " frames but there are only "
> >> ><< size << " frames in stack");
> >> > **/*
> >> > ...
> >> >
> >> >
> >> > Thanks,
> >> > Vladimir.
> >> >
> >> > On 9/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >>
> >> >>
> >> >> Vladimir Gorr wrote:
> >> >> > I was able to sucessfully run both applications (Eclipse &
> ActiveMQ)
> >> >> for
> >> >> > the
> >> >> > recent build.
> >> >>
> >> >> what changed?
> >> >>
> >> >> geir
> >> >>
> >> >> >
> >> >> > Thanks,
> >&

Re: [drlvm] Need help debugging

[Elena Semukhina]

Actually, the code should be fixed rather than commented out in the
following way:

   //--size;

   // skip the VMStart$MainThread.runImpl() if it exists from the bottom
   // of the stack along with 2 reflection frames used to invoke method
main

   static String* starter_String =
genv->string_pool.lookup("java/lang/VMStart$MainThread");
   Method_Handle method = frames[size - 1].method;
   assert(method);
   if (!strcmp(method_get_name(method), "runImpl")
   && method->get_class()->name == starter_String) {
   for (; --size;) {
   method = frames[size - 1].method;
   assert(method);
   if ((strstr(method->get_class()->name->bytes,
"java/lang/reflect"))
   == NULL) {
   break;
   }
   }
   }

   ASSERT(size >= skip, "Trying to skip " << skip
   << " frames but there are only "
   << size << " frames in stack");

The fix has been submitted in HARMONY-1431 which depends on HARMONY-1363.

As for Eclipse's silent exit, please try to find what has happened in the
eclipse/configuration/*.log files.

Thanks,
Elena

On 9/14/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


I'd like to understand why this is no longer necessary.

(Just provide some background for all of us to help start understanding
the structure and operation of DLRVM)

geir


Vladimir Gorr wrote:
> Probably, you didn't note I've commented this fragment of code (firts &
> last
> lines).
> Sorry I didn't mention about this before. After these changes I could
> sucessfully start the ActiveMQ.
> Before I have the following error:
>
> Assertion failed: size >= skip
> Trying to skip 6 frames but there are only 5 frames in stack
> java:
>
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
>
> _jobject* Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
> _jobject*, _jobject*): Assertion `size >= skip' failed.
> abort_handler()
>
> Thanks,
> Vladimir.
>
> On 9/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> I'm a little skeptical, as I had that change in before you first tested
>> and found a problem, right?
>>
>> geir
>>
>>
>> Vladimir Gorr wrote:
>> > vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
>> > ...
>> > * /*
>> > *// skip Thread.runImpl()
>> >size--;
>> >
>> >// skip the VMStart$MainThread if one exits from the bottom of the
>> stack
>> >// along with 2 reflection frames used to invoke method main
>> >static String* starter_String =
>> > genv->string_pool.lookup("java/lang/VMStart$MainThread");
>> >Method_Handle method = frames[size].method;
>> >assert(method);
>> >// skip only for main application thread
>> >if (!strcmp(method_get_name(method), "runImpl")
>> >&& method->get_class()->name == starter_String) {
>> >int rem = size - skip-1;
>> >size -= rem < 2 ? rem : 2;
>> >}
>> >ASSERT(size >= skip, "Trying to skip " << skip
>> ><< " frames but there are only "
>> ><< size << " frames in stack");
>> > **/*
>> > ...
>> >
>> >
>> > Thanks,
>> > Vladimir.
>> >
>> > On 9/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> Vladimir Gorr wrote:
>> >> > I was able to sucessfully run both applications (Eclipse &
ActiveMQ)
>> >> for
>> >> > the
>> >> > recent build.
>> >>
>> >> what changed?
>> >>
>> >> geir
>> >>
>> >> >
>> >> > Thanks,
>> >> > Vladimir.
>> >> >
>> >> > On 9/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> doh.  Thanks.  I feel dumb for not trying the simplest thing
first
>> :)
>> >> >>
>> >> >> There's a test...
>> >> >>
>> >> >> geir
>> >> >>
>> >> >>
>> >> >> Anton Luht wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > The 'java -jar' launcher prints dump and exits even on a
minimal
>> >> >> > HelloWorld app jar - please see
>> >> >> > http://issues.apache.org/jira/browse/HARMONY-1444
>> >> >> >
>> >> >> > On 9/12/06, Anton Luht <[EMAIL PROTECTED]> wrote:
>> >> >> >> No, I used hand-made build from SVN.
>> >> >> >>
>> >> >> >> BTW, sorry for confusion about 'broken data'. The pointer
value
>> is
>> >> >> >> changed inside the method - this assignment should be removed.
>> >> >> >>
>> >> >> >> On 9/12/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>> >> >> >> > Did you run this application for the recent binaries got
from
>> the
>> >> >> SVN
>> >> >> >> > sources?
>> >> >> >> > As for me my results differ from Geir ones, namely, DRLVM
>> crashes
>> >> >> >> for both
>> >> >> >> > Windows & Linux as follows:
>> >> >> >> >
>> >> >> >> > ===
>> >> >> >> > Windows
>> >> >> >> > ===
>> >> >> >> >
>> >> >> >> > vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
>> >> >> >> > $ echo JAVA_HOME
>> >> >> >> > JAVA_HOME
>> >> >> >> >
>> >> >> >> > vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
>> >> >> >> > $ echo $CLASSPATH
>> >> >> >> > c:/Tools/incubator-activemq-4.0/lib
>> >> >> >> >
>> >> >> >> > vgorr@ /cygdrive/c/

Re: towards a new implementation of java.math

[Elena Semukhina]

On 5/17/06, Daniel Fridlender <[EMAIL PROTECTED]> wrote:


Hi,

After a discussion we had a few weeks ago in this forum on the
different implementations of java.math donated to Harmony
(Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
the task of integrating them into a single implementation which would
benefit from the best features of Harmony-39, 380 and 199.

We will consider comparing on a method-by-method level but also on
ideas level so that the new implementation will probably require
re-programming good ideas from the existing implementations.  In the
case of BigInteger we will also compare the benefits of the different
internal representations.

Right now we are analysing the two implementations.  Once we are done
with this analysis we will make it public and propose a way to proceed
towards an integration.

BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
to erase non-existing lines.  Did we miss something?  Is there any
other intermediate patch that we have missed?



Daniel,
you've missed Harmony-273 which inserts javadoc comments in the source code.

--
Thanks,
Elena

Regards,


Daniel Fridlender
ITC

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.

[Elena Semukhina (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-66?page=comments#action_12365048 ] 

Elena Semukhina commented on HARMONY-66:


Tim,

this time the fix looks fine and the test passes.


> java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException 
> for the dead thread.
> 
>
>  Key: HARMONY-66
>  URL: http://issues.apache.org/jira/browse/HARMONY-66
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Elena Semukhina
> Assignee: Tim Ellison
> Priority: Minor

>
> java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException 
> for the dead thread.
> According to specification, the Thread.getThreadGroup() method returns null 
> if this thread has died.
> SecurityManager.checkAccess(Thread t) should take that into account.
> Code for reproducing:
> public class ThreadCheckAccess {
> class ThreadRunning extends Thread {
> volatile boolean stopWork = false;
> int i = 0;
> public void run () {
> while (!stopWork) {
> }
> }
> }
> public void test() {
> SecurityManager sm = new SecurityManager();
> System.setSecurityManager(sm);
> ThreadRunning t = new ThreadRunning();
> t.start();
> t.stopWork = true;
> try {
> t.join();
> } catch (InterruptedException e) {
> e.printStackTrace();  
> }
> try {
> sm.checkAccess(t);
> System.out.println("PASSED");
> } catch (NullPointerException e) {
> e.printStackTrace();
> System.out.println("FAILED");
> }
> }
> public static void main(String args[]) {
> new ThreadCheckAccess().test();
> }
> }
> Steps to Reproduce: 
> 1. Build Harmony (check-out on 2006-01-31) j2se subset as described in 
> README.txt.
> 2. Compile ThreadCheckAccess.java using BEA 1.4 javac 
> > javac -d . ThreadCheckAccess.java 
> 2. Run java using compatible VM (J9) 
> > java -showversion ThreadCheckAccess 
>   
> Output: 
> java version 1.4.2 (subset) 
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
> applicable. 
> java.lang.NullPointerException
> at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
> at java.lang.Thread.checkAccess(Thread.java:423)
> at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
> at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
> FAILED
> Output on BEA 1.4.2: 
> PASSED
> Suggested junit test case: 
> package org.apache.harmony.tests.java.lang; 
> import junit.framework.TestCase; 
> public class SecurityManagerTest extends TestCase { 
> class ThreadRunning extends Thread {
> volatile boolean stopWork = false;
> int i = 0;
> public void run () {
> while (!stopWork) {
> }
> }
> }
> public void test_checkAccessLjava_lang_Thread() { 
> SecurityManager sm = new SecurityManager();
> System.setSecurityManager(sm);
> ThreadRunning t = new ThreadRunning();
> t.start();
> t.stopWork = true;
> try {
> t.join();
> } catch (InterruptedException e) {
> fail("Assert 0: unexpected " + e);  
> }
> try {
> sm.checkAccess(t);
> } catch (NullPointerException e) {
> fail("Assert 1: NullPointerException has been thrown");
> }
> } 
> } 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.

[Elena Semukhina (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-66?page=comments#action_12364939 ] 

Elena Semukhina commented on HARMONY-66:


Tim,

unfortunately the fix is not correct. Now the test fails on checking permission 
as follows:

Exception in thread "main" java.security.AccessControlException: Access denied 
(java.lang.RuntimePermission modifyThread)
at java.security.AccessController.checkPermission(AccessController.java:
90)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:704)
at java.lang.SecurityManager.checkAccess(SecurityManager.java:94)
at ThreadCheckAccess.test(ThreadCheckAccess.java:24)
at ThreadCheckAccess.main(ThreadCheckAccess.java:33)

The point is that SecurityManager.checkAccess(Thread) should call 
checkPermission only for system threads, otherwise it should return silently.



> java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException 
> for the dead thread.
> 
>
>  Key: HARMONY-66
>  URL: http://issues.apache.org/jira/browse/HARMONY-66
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Elena Semukhina
> Assignee: Tim Ellison
> Priority: Minor

>
> java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException 
> for the dead thread.
> According to specification, the Thread.getThreadGroup() method returns null 
> if this thread has died.
> SecurityManager.checkAccess(Thread t) should take that into account.
> Code for reproducing:
> public class ThreadCheckAccess {
> class ThreadRunning extends Thread {
> volatile boolean stopWork = false;
> int i = 0;
> public void run () {
> while (!stopWork) {
> }
> }
> }
> public void test() {
> SecurityManager sm = new SecurityManager();
> System.setSecurityManager(sm);
> ThreadRunning t = new ThreadRunning();
> t.start();
> t.stopWork = true;
> try {
> t.join();
> } catch (InterruptedException e) {
> e.printStackTrace();  
> }
> try {
> sm.checkAccess(t);
> System.out.println("PASSED");
> } catch (NullPointerException e) {
> e.printStackTrace();
> System.out.println("FAILED");
> }
> }
> public static void main(String args[]) {
> new ThreadCheckAccess().test();
> }
> }
> Steps to Reproduce: 
> 1. Build Harmony (check-out on 2006-01-31) j2se subset as described in 
> README.txt.
> 2. Compile ThreadCheckAccess.java using BEA 1.4 javac 
> > javac -d . ThreadCheckAccess.java 
> 2. Run java using compatible VM (J9) 
> > java -showversion ThreadCheckAccess 
>   
> Output: 
> java version 1.4.2 (subset) 
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
> applicable. 
> java.lang.NullPointerException
> at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
> at java.lang.Thread.checkAccess(Thread.java:423)
> at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
> at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
> FAILED
> Output on BEA 1.4.2: 
> PASSED
> Suggested junit test case: 
> package org.apache.harmony.tests.java.lang; 
> import junit.framework.TestCase; 
> public class SecurityManagerTest extends TestCase { 
> class ThreadRunning extends Thread {
> volatile boolean stopWork = false;
> int i = 0;
> public void run () {
> while (!stopWork) {
> }
> }
> }
> public void test_checkAccessLjava_lang_Thread() { 
> SecurityManager sm = new SecurityManager();
> System.setSecurityManager(sm);
> ThreadRunning t = new ThreadRunning();
> t.start();
> t.stopWork = true;
> try {
> t.join();
> } catch (InterruptedException e) {
> fail("Assert 0: unexpected " + e);  
> }
> try {
> sm.checkAccess(t);
> } catch (NullPointerException e) {
> fail("Assert 1: NullPointerException has been thrown");
> }
> } 
> } 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.

[Elena Semukhina (JIRA)]

java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for 
the dead thread.


 Key: HARMONY-66
 URL: http://issues.apache.org/jira/browse/HARMONY-66
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Elena Semukhina
Priority: Minor


java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for 
the dead thread.

According to specification, the Thread.getThreadGroup() method returns null if 
this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.

Code for reproducing:

public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;

public void run () {
while (!stopWork) {
}
}
}

public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();  
}
try {
sm.checkAccess(t);
System.out.println("PASSED");
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println("FAILED");
}
}

public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}

Steps to Reproduce: 
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in 
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac 
> javac -d . ThreadCheckAccess.java 
2. Run java using compatible VM (J9) 
> java -showversion ThreadCheckAccess 
  
Output: 
java version 1.4.2 (subset) 

(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
applicable. 
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED

Output on BEA 1.4.2: 

PASSED

Suggested junit test case: 

package org.apache.harmony.tests.java.lang; 

import junit.framework.TestCase; 

public class SecurityManagerTest extends TestCase { 
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;

public void run () {
while (!stopWork) {
}
}
}

public void test_checkAccessLjava_lang_Thread() { 
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail("Assert 0: unexpected " + e);  
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail("Assert 1: NullPointerException has been thrown");
}
} 
} 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira