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

[Geir Magnusson Jr.]

I spoke too soon - do you mean reusing the code for managing the exclude 
lists?


geir


Geir Magnusson Jr. wrote:



Tim Ellison wrote:

Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.


It ties us to JUnit.  Doesn't moving the exclude list upwards give us 
more freedom?


geir



Thanks
Tim

Alexei Zakharov wrote:

Hi Vladimir,

It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.

For example, we can put exclude lists into something like:

exclude.xml:
---

 
 
   
   
 
 
 
...


exclude.linux.drlvm.xml:
---

 
   
 


And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.

IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?

Thanks,


2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we
mark test
by correct tags.
When the test fails on some platform we update the corresponding
x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

 Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:

Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I

hope in

this

case the test enabling for the different platforms will be easy.

Please,

look at it.

Any comments are welcome :)



 Thanks, Vladimir


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

Pavel, you are correct. Rana, sorry for confusion. Both issues

block

passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one

contains

three diffrent issues, and I cannot say where exactly the

problem is.

On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:

As I understand Alexey means HARMONY-2073, but not HARMONY-2070.

Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?


Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

OK thanks Pavel, I'll try the patch today.

Rana


On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:

Hi Rana.



I extend guard region as work around. It's only one way,

which

"fix"

SOE

on
my SuSE Linux, without potential regression of your fix.

On my

Linux

machine
violation access signals happen one page before protected

page

on

the

stack.
It's it.



I ran all tests, and everything was OK. But strange

misprint was

fount

in

the new test.

So I attach new fixed patch.



Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

Though I tried several times, I could not repro 2070 or

Alexey's

specific

problems. The test attached to 2018 repros, and that I

think

is

enough.

Pavel,
  1. The patch looks good, but I could not apply and try it

since

my

Linux

box is down.
  2. Did you run all tests ( smoke, cuint, kernel, and

classlib )?

Since

this fully turns on lazy exceptions, we need to ensure that

all

tests

pass,
or at least have identical behaviour before and after the

pacth.

  3. Adding a finalizer based stack test to smoke is a good

idea.

  4. On Linux you extend the guard region up ( or down

whatever )

by a

page. Did you find a good reason for it, or is this just

being

careful?

Rana




On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]>

wrote:

Rana,

Everything is correct in you description, but it looks

like

that

*

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

[Geir Magnusson Jr.]

Tim Ellison wrote:

Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.


It ties us to JUnit.  Doesn't moving the exclude list upwards give us 
more freedom?


geir



Thanks
Tim

Alexei Zakharov wrote:

Hi Vladimir,

It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.

For example, we can put exclude lists into something like:

exclude.xml:
---

 
 
   
   
 
 
 
...


exclude.linux.drlvm.xml:
---

 
   
 


And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.

IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?

Thanks,


2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we
mark test
by correct tags.
When the test fails on some platform we update the corresponding
x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

 Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:

Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I

hope in

this

case the test enabling for the different platforms will be easy.

Please,

look at it.

Any comments are welcome :)



 Thanks, Vladimir


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

Pavel, you are correct. Rana, sorry for confusion. Both issues

block

passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one

contains

three diffrent issues, and I cannot say where exactly the

problem is.

On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:

As I understand Alexey means HARMONY-2073, but not HARMONY-2070.

Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?


Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

OK thanks Pavel, I'll try the patch today.

Rana


On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:

Hi Rana.



I extend guard region as work around. It's only one way,

which

"fix"

SOE

on
my SuSE Linux, without potential regression of your fix.

On my

Linux

machine
violation access signals happen one page before protected

page

on

the

stack.
It's it.



I ran all tests, and everything was OK. But strange

misprint was

fount

in

the new test.

So I attach new fixed patch.



Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

Though I tried several times, I could not repro 2070 or

Alexey's

specific

problems. The test attached to 2018 repros, and that I

think

is

enough.

Pavel,
  1. The patch looks good, but I could not apply and try it

since

my

Linux

box is down.
  2. Did you run all tests ( smoke, cuint, kernel, and

classlib )?

Since

this fully turns on lazy exceptions, we need to ensure that

all

tests

pass,
or at least have identical behaviour before and after the

pacth.

  3. Adding a finalizer based stack test to smoke is a good

idea.

  4. On Linux you extend the guard region up ( or down

whatever )

by a

page. Did you find a good reason for it, or is this just

being

careful?

Rana




On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]>

wrote:

Rana,

Everything is correct in you description, but it looks

like

that

*

HARMONY-2018* <

https://issues.apache.org/jira/browse/HARMONY-2018>

should

fix described bug. I think Alexei wil

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

[Vladimir Ivanov]

Issue 2197 was updated to exclude test by the simplest way (very simple
exclude files).

The next step will be looking through the issue 263. I'll try it.

It will fine if somebody take care about issue 2197 (exclude files for
win/lnx on x86 for IBM and DRl VMs).



Thanks, Vladimir



On 11/17/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:


Hi Vladimir,

It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.

For example, we can put exclude lists into something like:

exclude.xml:
---



   
   



...


exclude.linux.drlvm.xml:
---


   



And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.

IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?

Thanks,


2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> Seems, we says about different things :)
>
> First of all, we have no TestNG (or other harness) yet but we need now
> different exclude lists for different platforms.
>
> Also, in my vision these exclude-lists are like a buffer before we mark
test
> by correct tags.
> When the test fails on some platform we update the corresponding x-list
and
> investigate this failure.
> As the result of investigation we mark the test or fix it.
>
>  Thanks, Vladimir
>
>
> On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
> >
> > Things become more and more complicated. Can anyone say why we
> > rejected to use TestSuites for this purpose from the very beginning?
> > Well, I can't say I am against using xml lists here. But the next step
> > will be to keep list of individual failing test methods in the xml
> > file. Then to create separate xml lists for api and impl tests and so
> > on. If we can't run original TestNG on Harmony then we invent it by
> > ourselves. :-)
> >
> > Thanks,
> >
> > 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> > > As part of solution for this issue the
> > > *HARMONY-2197*
was
> > > created.
> > >
> > > I suggest using the separate exclude list for each platform. I hope
in
> > this
> > > case the test enabling for the different platforms will be easy.
Please,
> > > look at it.
> > >
> > > Any comments are welcome :)
> > >
> > >
> > >
> > >  Thanks, Vladimir
> > >
> > >
> > > On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pavel, you are correct. Rana, sorry for confusion. Both issues
block
> > > > passing class library unit tests.
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > > Unhandled exception in java.exe while java.util.jar module tests
> > > > execution
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > > >
> > > > I've used a debugger and caught an assert in
> > > > exn_raise_by_name_internal for the second one. The first one
contains
> > > > three diffrent issues, and I cannot say where exactly the problem
is.
> > > >
> > > > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > > >
> > > > > Alexei, is it correct? If not, could you clarify the point about
> > > > > exn_raise_by_name_internal in your initial letter, please?
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > OK thanks Pavel, I'll try the patch today.
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Hi Rana.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I extend guard region as work around. It's only one way,
which
> > "fix"
> > > > SOE
> > > > > > > on
> > > > > > > my SuSE Linux, without potential regression of your fix. On
my
> > Linux
> > > >
> > > > > > > machine
> > > > > > > violation access signals happen one page before protected
page
> > on
> > > > the
> > > > > > > stack.
> > > > > > > It's it.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I ran all tests, and everything was OK. But strange misprint
was
> > > > fount
> > > > > > in
> > > > > > > the new test.
> > > > > > >
> > > > > > > So I attach new fixed patch.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Pavel Afremov.
> > > > > > >
> > > > > > >
> > > > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > Though I

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

[Tim Ellison]

Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.

Thanks
Tim

Alexei Zakharov wrote:
> Hi Vladimir,
> 
> It seems everybody likes this approach. In that case, I have another
> idea for exclude lists. Can't we go further and extend the current
> exclude list functionality a bit more? And forget about TestNG and
> friends for a while I mean.
> 
> For example, we can put exclude lists into something like:
> 
> exclude.xml:
> ---
> 
>  
>  
>
>
>  
>  
>   includeAll="true"/>
> ...
> 
> 
> exclude.linux.drlvm.xml:
> ---
> 
>  
>
>  
> 
> 
> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
> controller test suite by ant. By the controller test suite I mean the
> java class that knows how to parse the above files (using simple SAX
> parser for example - it is easy, I can help if needed) and implements
> junit TestSuite model to get fine-grained control over the testing
> process.
> 
> IMHO this can be a nice solution for now. It's more powerful since it
> allows to exclude individual tests rather that whole classes. What do
> you think?
> 
> Thanks,
> 
> 
> 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> Seems, we says about different things :)
>>
>> First of all, we have no TestNG (or other harness) yet but we need now
>> different exclude lists for different platforms.
>>
>> Also, in my vision these exclude-lists are like a buffer before we
>> mark test
>> by correct tags.
>> When the test fails on some platform we update the corresponding
>> x-list and
>> investigate this failure.
>> As the result of investigation we mark the test or fix it.
>>
>>  Thanks, Vladimir
>>
>>
>> On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>> >
>> > Things become more and more complicated. Can anyone say why we
>> > rejected to use TestSuites for this purpose from the very beginning?
>> > Well, I can't say I am against using xml lists here. But the next step
>> > will be to keep list of individual failing test methods in the xml
>> > file. Then to create separate xml lists for api and impl tests and so
>> > on. If we can't run original TestNG on Harmony then we invent it by
>> > ourselves. :-)
>> >
>> > Thanks,
>> >
>> > 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> > > As part of solution for this issue the
>> > > *HARMONY-2197* was
>> > > created.
>> > >
>> > > I suggest using the separate exclude list for each platform. I
>> hope in
>> > this
>> > > case the test enabling for the different platforms will be easy.
>> Please,
>> > > look at it.
>> > >
>> > > Any comments are welcome :)
>> > >
>> > >
>> > >
>> > >  Thanks, Vladimir
>> > >
>> > >
>> > > On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Pavel, you are correct. Rana, sorry for confusion. Both issues
>> block
>> > > > passing class library unit tests.
>> > > >
>> > > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>> > > > Unhandled exception in java.exe while java.util.jar module tests
>> > > > execution
>> > > >
>> > > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>> > > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>> > > >
>> > > > I've used a debugger and caught an assert in
>> > > > exn_raise_by_name_internal for the second one. The first one
>> contains
>> > > > three diffrent issues, and I cannot say where exactly the
>> problem is.
>> > > >
>> > > > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
>> > > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>> > > > >
>> > > > > Alexei, is it correct? If not, could you clarify the point about
>> > > > > exn_raise_by_name_internal in your initial letter, please?
>> > > > >
>> > > > >
>> > > > > Pavel Afremov.
>> > > > >
>> > > > >
>> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> > > > > >
>> > > > > > OK thanks Pavel, I'll try the patch today.
>> > > > > >
>> > > > > > Rana
>> > > > > >
>> > > > > >
>> > > > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
>> > > > > > >
>> > > > > > > Hi Rana.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > I extend guard region as work around. It's only one way,
>> which
>> > "fix"
>> > > > SOE
>> > > > > > > on
>> > > > > > > my SuSE Linux, without potential regression of your fix.
>> On my
>> > Linux
>> > > >
>> > > > > > > machine
>> > > > > > > violation access signals happen one page before protected
>> page
>> > on
>> > > > the
>> > > > > > > stack.
>> > > > > > > It's it.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > I ran all tests, and everything was OK. But strange
>> misprint was
>> > > > fount
>> > > > > > in
>> > > > > > > the new test.
>> > > > > > >
>> > > > > > > So I attach new fixed patch.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Pavel Afremov.
>> > > > > > >
>> > > > > > >
>> > > > > > > On 11/8/06, Rana Dasgupta <[E

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

[Alexei Zakharov]

Hi Vladimir,

It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.

For example, we can put exclude lists into something like:

exclude.xml:
---

 
 
   
   
 
 
 
...


exclude.linux.drlvm.xml:
---

 
   
 


And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.

IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?

Thanks,


2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we mark test
by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

 Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>
> Things become more and more complicated. Can anyone say why we
> rejected to use TestSuites for this purpose from the very beginning?
> Well, I can't say I am against using xml lists here. But the next step
> will be to keep list of individual failing test methods in the xml
> file. Then to create separate xml lists for api and impl tests and so
> on. If we can't run original TestNG on Harmony then we invent it by
> ourselves. :-)
>
> Thanks,
>
> 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> > As part of solution for this issue the
> > *HARMONY-2197* was
> > created.
> >
> > I suggest using the separate exclude list for each platform. I hope in
> this
> > case the test enabling for the different platforms will be easy. Please,
> > look at it.
> >
> > Any comments are welcome :)
> >
> >
> >
> >  Thanks, Vladimir
> >
> >
> > On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> > >
> > > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > > passing class library unit tests.
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > Unhandled exception in java.exe while java.util.jar module tests
> > > execution
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > >
> > > I've used a debugger and caught an assert in
> > > exn_raise_by_name_internal for the second one. The first one contains
> > > three diffrent issues, and I cannot say where exactly the problem is.
> > >
> > > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > >
> > > > Alexei, is it correct? If not, could you clarify the point about
> > > > exn_raise_by_name_internal in your initial letter, please?
> > > >
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > OK thanks Pavel, I'll try the patch today.
> > > > >
> > > > > Rana
> > > > >
> > > > >
> > > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Rana.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I extend guard region as work around. It's only one way, which
> "fix"
> > > SOE
> > > > > > on
> > > > > > my SuSE Linux, without potential regression of your fix. On my
> Linux
> > >
> > > > > > machine
> > > > > > violation access signals happen one page before protected page
> on
> > > the
> > > > > > stack.
> > > > > > It's it.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I ran all tests, and everything was OK. But strange misprint was
> > > fount
> > > > > in
> > > > > > the new test.
> > > > > >
> > > > > > So I attach new fixed patch.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pavel Afremov.
> > > > > >
> > > > > >
> > > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Though I tried several times, I could not repro 2070 or
> Alexey's
> > > > > > specific
> > > > > > > problems. The test attached to 2018 repros, and that I think
> is
> > > > > enough.
> > > > > > >
> > > > > > > Pavel,
> > > > > > >   1. The patch looks good, but I could not apply and try it
> since
> > > my
> > > > > > Linux
> > > > > > > box is down.
> > > > > > >   2. Did you run all tests ( smoke, cuint, kernel, and
> classlib )?
> > >
> > > > > Since
> > > > > > > this fully turns on lazy exceptions, we need to ensure that
> all
> > > tests
> > > > > > 

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

[Tim Ellison]

Vladimir Ivanov wrote:
> As variant, the java from 'test.jre.home' may be run with "-version" 
> option and output may be parsed and mapped to some value. In this
> case all Harmony VM should support this option and print different
> messages. Is it OK?
> 
> I suggest implementing version with hard coded vm name and than 
> extend it by auto-detecting capability.

Sure give it a try and let us know what it takes.

Regards,
Tim

-- 

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

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

[Alexey Varlamov]

+1
I like this approach too - more flexible than current.

2006/11/16, Vladimir Ivanov <[EMAIL PROTECTED]>:

On 11/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Vladimir Ivanov wrote:
> > As part of solution for this issue the
> > *HARMONY-2197* was
> > created.
> >
> > I suggest using the separate exclude list for each platform. I hope in
> this
> > case the test enabling for the different platforms will be easy. Please,
> > look at it.
> >
> > Any comments are welcome :)
>
> Maybe a dumb question by why hard-code
>
> 
>
> Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
> a short form suitable as a directory name?



Actually, this property is defined before the test run by Ant's VM. In my
case it is

'Java HotSpot(TM) Client VM'.



As variant, the java from 'test.jre.home' may be run with "-version" option
and output may be parsed and mapped to some value. In this case all Harmony
VM should support this option and print different messages. Is it OK?



I suggest implementing version with hard coded vm name and than extend it by
auto-detecting capability.



 Thanks, Vladimir



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

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

[Vladimir Ivanov]

On 11/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)

Maybe a dumb question by why hard-code



Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
a short form suitable as a directory name?




Actually, this property is defined before the test run by Ant's VM. In my
case it is

'Java HotSpot(TM) Client VM'.



As variant, the java from 'test.jre.home' may be run with "-version" option
and output may be parsed and mapped to some value. In this case all Harmony
VM should support this option and print different messages. Is it OK?



I suggest implementing version with hard coded vm name and than extend it by
auto-detecting capability.



Thanks, Vladimir




Regards,
Tim

--

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

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

[Tim Ellison]

Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
> 
> I suggest using the separate exclude list for each platform. I hope in this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
> 
> Any comments are welcome :)

Maybe a dumb question by why hard-code

  

Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
a short form suitable as a directory name?

Regards,
Tim

-- 

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

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

[Geir Magnusson Jr.]

We should also take a hard look at how to do this in DRLVM as well...

Vladimir Ivanov wrote:

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we mark 
test

by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:


Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. 
Please,

> look at it.
>
> Any comments are welcome :)
>
>
>
>  Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> >
> > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > passing class library unit tests.
> >
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > Unhandled exception in java.exe while java.util.jar module tests
> > execution
> >
> > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >
> > I've used a debugger and caught an assert in
> > exn_raise_by_name_internal for the second one. The first one contains
> > three diffrent issues, and I cannot say where exactly the problem is.
> >
> > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > >
> > > Alexei, is it correct? If not, could you clarify the point about
> > > exn_raise_by_name_internal in your initial letter, please?
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK thanks Pavel, I'll try the patch today.
> > > >
> > > > Rana
> > > >
> > > >
> > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Rana.
> > > > >
> > > > >
> > > > >
> > > > > I extend guard region as work around. It's only one way, which
"fix"
> > SOE
> > > > > on
> > > > > my SuSE Linux, without potential regression of your fix. On my
Linux
> >
> > > > > machine
> > > > > violation access signals happen one page before protected page
on
> > the
> > > > > stack.
> > > > > It's it.
> > > > >
> > > > >
> > > > >
> > > > > I ran all tests, and everything was OK. But strange misprint 
was

> > fount
> > > > in
> > > > > the new test.
> > > > >
> > > > > So I attach new fixed patch.
> > > > >
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Though I tried several times, I could not repro 2070 or
Alexey's
> > > > > specific
> > > > > > problems. The test attached to 2018 repros, and that I think
is
> > > > enough.
> > > > > >
> > > > > > Pavel,
> > > > > >   1. The patch looks good, but I could not apply and try it
since
> > my
> > > > > Linux
> > > > > > box is down.
> > > > > >   2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
> >
> > > > Since
> > > > > > this fully turns on lazy exceptions, we need to ensure that
all
> > tests
> > > > > > pass,
> > > > > > or at least have identical behaviour before and after the
pacth.
> > > > > >   3. Adding a finalizer based stack test to smoke is a good
idea.
> > > > > >   4. On Linux you extend the guard region up ( or down
whatever )
> > by a
> > > > > > page. Did you find a good reason for it, or is this just 
being

> > > > careful?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Rana,
> > > > > > >
> > > > > > > Everything is correct in you description, but it looks like
that
> > *
> > > > > > > HARMONY-2018* <
> > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > should
> > > > > > > fix described bug. I think Alexei will have a chance to
check
> > it.

--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Geir Magnusson Jr.]

I like this approach.

+1

(it's exactly how I would have done it. :)

Vladimir Ivanov wrote:

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I hope in this
case the test enabling for the different platforms will be easy. Please,
look at it.

Any comments are welcome :)



Thanks, Vladimir


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


Pavel, you are correct. Rana, sorry for confusion. Both issues block
passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one contains
three diffrent issues, and I cannot say where exactly the problem is.

On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>
> Alexei, is it correct? If not, could you clarify the point about
> exn_raise_by_name_internal in your initial letter, please?
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> > OK thanks Pavel, I'll try the patch today.
> >
> > Rana
> >
> >
> > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Rana.
> > >
> > >
> > >
> > > I extend guard region as work around. It's only one way, which 
"fix"

SOE
> > > on
> > > my SuSE Linux, without potential regression of your fix. On my 
Linux


> > > machine
> > > violation access signals happen one page before protected page on
the
> > > stack.
> > > It's it.
> > >
> > >
> > >
> > > I ran all tests, and everything was OK. But strange misprint was
fount
> > in
> > > the new test.
> > >
> > > So I attach new fixed patch.
> > >
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > specific
> > > > problems. The test attached to 2018 repros, and that I think is
> > enough.
> > > >
> > > > Pavel,
> > > >   1. The patch looks good, but I could not apply and try it since
my
> > > Linux
> > > > box is down.
> > > >   2. Did you run all tests ( smoke, cuint, kernel, and 
classlib )?


> > Since
> > > > this fully turns on lazy exceptions, we need to ensure that all
tests
> > > > pass,
> > > > or at least have identical behaviour before and after the pacth.
> > > >   3. Adding a finalizer based stack test to smoke is a good idea.
> > > >   4. On Linux you extend the guard region up ( or down whatever )
by a
> > > > page. Did you find a good reason for it, or is this just being
> > careful?
> > > >
> > > > Rana
> > > >
> > > >
> > > >
> > > >
> > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Rana,
> > > > >
> > > > > Everything is correct in you description, but it looks like 
that

*
> > > > > HARMONY-2018* <
https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > should
> > > > > fix described bug. I think Alexei will have a chance to check
it.
> > > > >
> > > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


--
Thank you,
Alexei

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

[Vladimir Ivanov]

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we mark test
by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:


Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)
>
>
>
>  Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> >
> > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > passing class library unit tests.
> >
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > Unhandled exception in java.exe while java.util.jar module tests
> > execution
> >
> > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >
> > I've used a debugger and caught an assert in
> > exn_raise_by_name_internal for the second one. The first one contains
> > three diffrent issues, and I cannot say where exactly the problem is.
> >
> > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > >
> > > Alexei, is it correct? If not, could you clarify the point about
> > > exn_raise_by_name_internal in your initial letter, please?
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK thanks Pavel, I'll try the patch today.
> > > >
> > > > Rana
> > > >
> > > >
> > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Rana.
> > > > >
> > > > >
> > > > >
> > > > > I extend guard region as work around. It's only one way, which
"fix"
> > SOE
> > > > > on
> > > > > my SuSE Linux, without potential regression of your fix. On my
Linux
> >
> > > > > machine
> > > > > violation access signals happen one page before protected page
on
> > the
> > > > > stack.
> > > > > It's it.
> > > > >
> > > > >
> > > > >
> > > > > I ran all tests, and everything was OK. But strange misprint was
> > fount
> > > > in
> > > > > the new test.
> > > > >
> > > > > So I attach new fixed patch.
> > > > >
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Though I tried several times, I could not repro 2070 or
Alexey's
> > > > > specific
> > > > > > problems. The test attached to 2018 repros, and that I think
is
> > > > enough.
> > > > > >
> > > > > > Pavel,
> > > > > >   1. The patch looks good, but I could not apply and try it
since
> > my
> > > > > Linux
> > > > > > box is down.
> > > > > >   2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
> >
> > > > Since
> > > > > > this fully turns on lazy exceptions, we need to ensure that
all
> > tests
> > > > > > pass,
> > > > > > or at least have identical behaviour before and after the
pacth.
> > > > > >   3. Adding a finalizer based stack test to smoke is a good
idea.
> > > > > >   4. On Linux you extend the guard region up ( or down
whatever )
> > by a
> > > > > > page. Did you find a good reason for it, or is this just being
> > > > careful?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Rana,
> > > > > > >
> > > > > > > Everything is correct in you description, but it looks like
that
> > *
> > > > > > > HARMONY-2018* <
> > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > should
> > > > > > > fix described bug. I think Alexei will have a chance to
check
> > it.

--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Alexei Zakharov]

Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I hope in this
case the test enabling for the different platforms will be easy. Please,
look at it.

Any comments are welcome :)



 Thanks, Vladimir


On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>
> Pavel, you are correct. Rana, sorry for confusion. Both issues block
> passing class library unit tests.
>
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> Unhandled exception in java.exe while java.util.jar module tests
> execution
>
> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>
> I've used a debugger and caught an assert in
> exn_raise_by_name_internal for the second one. The first one contains
> three diffrent issues, and I cannot say where exactly the problem is.
>
> On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> >
> > Alexei, is it correct? If not, could you clarify the point about
> > exn_raise_by_name_internal in your initial letter, please?
> >
> >
> > Pavel Afremov.
> >
> >
> > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > >
> > > OK thanks Pavel, I'll try the patch today.
> > >
> > > Rana
> > >
> > >
> > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Rana.
> > > >
> > > >
> > > >
> > > > I extend guard region as work around. It's only one way, which "fix"
> SOE
> > > > on
> > > > my SuSE Linux, without potential regression of your fix. On my Linux
>
> > > > machine
> > > > violation access signals happen one page before protected page on
> the
> > > > stack.
> > > > It's it.
> > > >
> > > >
> > > >
> > > > I ran all tests, and everything was OK. But strange misprint was
> fount
> > > in
> > > > the new test.
> > > >
> > > > So I attach new fixed patch.
> > > >
> > > >
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > > specific
> > > > > problems. The test attached to 2018 repros, and that I think is
> > > enough.
> > > > >
> > > > > Pavel,
> > > > >   1. The patch looks good, but I could not apply and try it since
> my
> > > > Linux
> > > > > box is down.
> > > > >   2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
>
> > > Since
> > > > > this fully turns on lazy exceptions, we need to ensure that all
> tests
> > > > > pass,
> > > > > or at least have identical behaviour before and after the pacth.
> > > > >   3. Adding a finalizer based stack test to smoke is a good idea.
> > > > >   4. On Linux you extend the guard region up ( or down whatever )
> by a
> > > > > page. Did you find a good reason for it, or is this just being
> > > careful?
> > > > >
> > > > > Rana
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Rana,
> > > > > >
> > > > > > Everything is correct in you description, but it looks like that
> *
> > > > > > HARMONY-2018* <
> https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > should
> > > > > > fix described bug. I think Alexei will have a chance to check
> it.


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Vladimir Ivanov]

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I hope in this
case the test enabling for the different platforms will be easy. Please,
look at it.

Any comments are welcome :)



Thanks, Vladimir


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


Pavel, you are correct. Rana, sorry for confusion. Both issues block
passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one contains
three diffrent issues, and I cannot say where exactly the problem is.

On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>
> Alexei, is it correct? If not, could you clarify the point about
> exn_raise_by_name_internal in your initial letter, please?
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> > OK thanks Pavel, I'll try the patch today.
> >
> > Rana
> >
> >
> > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Rana.
> > >
> > >
> > >
> > > I extend guard region as work around. It's only one way, which "fix"
SOE
> > > on
> > > my SuSE Linux, without potential regression of your fix. On my Linux

> > > machine
> > > violation access signals happen one page before protected page on
the
> > > stack.
> > > It's it.
> > >
> > >
> > >
> > > I ran all tests, and everything was OK. But strange misprint was
fount
> > in
> > > the new test.
> > >
> > > So I attach new fixed patch.
> > >
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > specific
> > > > problems. The test attached to 2018 repros, and that I think is
> > enough.
> > > >
> > > > Pavel,
> > > >   1. The patch looks good, but I could not apply and try it since
my
> > > Linux
> > > > box is down.
> > > >   2. Did you run all tests ( smoke, cuint, kernel, and classlib )?

> > Since
> > > > this fully turns on lazy exceptions, we need to ensure that all
tests
> > > > pass,
> > > > or at least have identical behaviour before and after the pacth.
> > > >   3. Adding a finalizer based stack test to smoke is a good idea.
> > > >   4. On Linux you extend the guard region up ( or down whatever )
by a
> > > > page. Did you find a good reason for it, or is this just being
> > careful?
> > > >
> > > > Rana
> > > >
> > > >
> > > >
> > > >
> > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Rana,
> > > > >
> > > > > Everything is correct in you description, but it looks like that
*
> > > > > HARMONY-2018* <
https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > should
> > > > > fix described bug. I think Alexei will have a chance to check
it.
> > > > >
> > > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


--
Thank you,
Alexei

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

[Alexei Fedotov]

Pavel, you are correct. Rana, sorry for confusion. Both issues block
passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one contains
three diffrent issues, and I cannot say where exactly the problem is.

On 11/15/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:

As I understand Alexey means HARMONY-2073, but not HARMONY-2070.

Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?


Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> OK thanks Pavel, I'll try the patch today.
>
> Rana
>
>
> On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> >
> > Hi Rana.
> >
> >
> >
> > I extend guard region as work around. It's only one way, which "fix" SOE
> > on
> > my SuSE Linux, without potential regression of your fix. On my Linux
> > machine
> > violation access signals happen one page before protected page on the
> > stack.
> > It's it.
> >
> >
> >
> > I ran all tests, and everything was OK. But strange misprint was fount
> in
> > the new test.
> >
> > So I attach new fixed patch.
> >
> >
> >
> > Pavel Afremov.
> >
> >
> > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > >
> > > Though I tried several times, I could not repro 2070 or Alexey's
> > specific
> > > problems. The test attached to 2018 repros, and that I think is
> enough.
> > >
> > > Pavel,
> > >   1. The patch looks good, but I could not apply and try it since my
> > Linux
> > > box is down.
> > >   2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
> Since
> > > this fully turns on lazy exceptions, we need to ensure that all tests
> > > pass,
> > > or at least have identical behaviour before and after the pacth.
> > >   3. Adding a finalizer based stack test to smoke is a good idea.
> > >   4. On Linux you extend the guard region up ( or down whatever ) by a
> > > page. Did you find a good reason for it, or is this just being
> careful?
> > >
> > > Rana
> > >
> > >
> > >
> > >
> > > On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Rana,
> > > >
> > > > Everything is correct in you description, but it looks like that *
> > > > HARMONY-2018* 
> > > should
> > > > fix described bug. I think Alexei will have a chance to check it.
> > > >
> > > >
> > > >
> > > > Thank you.
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>





--
Thank you,
Alexei

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

[Pavel Afremov]

As I understand Alexey means HARMONY-2073, but not HARMONY-2070.

Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?


Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


OK thanks Pavel, I'll try the patch today.

Rana


On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
>
> Hi Rana.
>
>
>
> I extend guard region as work around. It's only one way, which "fix" SOE
> on
> my SuSE Linux, without potential regression of your fix. On my Linux
> machine
> violation access signals happen one page before protected page on the
> stack.
> It's it.
>
>
>
> I ran all tests, and everything was OK. But strange misprint was fount
in
> the new test.
>
> So I attach new fixed patch.
>
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> > Though I tried several times, I could not repro 2070 or Alexey's
> specific
> > problems. The test attached to 2018 repros, and that I think is
enough.
> >
> > Pavel,
> >   1. The patch looks good, but I could not apply and try it since my
> Linux
> > box is down.
> >   2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
Since
> > this fully turns on lazy exceptions, we need to ensure that all tests
> > pass,
> > or at least have identical behaviour before and after the pacth.
> >   3. Adding a finalizer based stack test to smoke is a good idea.
> >   4. On Linux you extend the guard region up ( or down whatever ) by a
> > page. Did you find a good reason for it, or is this just being
careful?
> >
> > Rana
> >
> >
> >
> >
> > On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > >
> > > Rana,
> > >
> > > Everything is correct in you description, but it looks like that *
> > > HARMONY-2018* 
> > should
> > > fix described bug. I think Alexei will have a chance to check it.
> > >
> > >
> > >
> > > Thank you.
> > >
> > > Pavel Afremov.
> > >
> > >
> > >
> >
> >
>
>

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

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

[Fedotov, Alexei A]

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

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

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

[Rana Dasgupta]

OK thanks Pavel, I'll try the patch today.

Rana


On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:


Hi Rana.



I extend guard region as work around. It's only one way, which "fix" SOE
on
my SuSE Linux, without potential regression of your fix. On my Linux
machine
violation access signals happen one page before protected page on the
stack.
It's it.



I ran all tests, and everything was OK. But strange misprint was fount in
the new test.

So I attach new fixed patch.



Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> Though I tried several times, I could not repro 2070 or Alexey's
specific
> problems. The test attached to 2018 repros, and that I think is enough.
>
> Pavel,
>   1. The patch looks good, but I could not apply and try it since my
Linux
> box is down.
>   2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
> this fully turns on lazy exceptions, we need to ensure that all tests
> pass,
> or at least have identical behaviour before and after the pacth.
>   3. Adding a finalizer based stack test to smoke is a good idea.
>   4. On Linux you extend the guard region up ( or down whatever ) by a
> page. Did you find a good reason for it, or is this just being careful?
>
> Rana
>
>
>
>
> On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> >
> > Rana,
> >
> > Everything is correct in you description, but it looks like that *
> > HARMONY-2018* 
> should
> > fix described bug. I think Alexei will have a chance to check it.
> >
> >
> >
> > Thank you.
> >
> > Pavel Afremov.
> >
> >
> >
>
>

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

[Pavel Afremov]

Hi Rana.



I extend guard region as work around. It's only one way, which "fix" SOE on
my SuSE Linux, without potential regression of your fix. On my Linux machine
violation access signals happen one page before protected page on the stack.
It's it.



I ran all tests, and everything was OK. But strange misprint was fount in
the new test.

So I attach new fixed patch.



Pavel Afremov.


On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


Though I tried several times, I could not repro 2070 or Alexey's specific
problems. The test attached to 2018 repros, and that I think is enough.

Pavel,
  1. The patch looks good, but I could not apply and try it since my Linux
box is down.
  2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
this fully turns on lazy exceptions, we need to ensure that all tests
pass,
or at least have identical behaviour before and after the pacth.
  3. Adding a finalizer based stack test to smoke is a good idea.
  4. On Linux you extend the guard region up ( or down whatever ) by a
page. Did you find a good reason for it, or is this just being careful?

Rana




On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
>
> Rana,
>
> Everything is correct in you description, but it looks like that *
> HARMONY-2018* 
should
> fix described bug. I think Alexei will have a chance to check it.
>
>
>
> Thank you.
>
> Pavel Afremov.
>
>
>

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

[Rana Dasgupta]

Though I tried several times, I could not repro 2070 or Alexey's specific
problems. The test attached to 2018 repros, and that I think is enough.

Pavel,
  1. The patch looks good, but I could not apply and try it since my Linux
box is down.
  2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
this fully turns on lazy exceptions, we need to ensure that all tests pass,
or at least have identical behaviour before and after the pacth.
  3. Adding a finalizer based stack test to smoke is a good idea.
  4. On Linux you extend the guard region up ( or down whatever ) by a
page. Did you find a good reason for it, or is this just being careful?

Rana




On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:


Rana,

Everything is correct in you description, but it looks like that *
HARMONY-2018*  should
fix described bug. I think Alexei will have a chance to check it.



Thank you.

Pavel Afremov.

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

[Pavel Afremov]

Rana,

Everything is correct in you description, but it looks like that *
HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018> should
fix described bug. I think Alexei will have a chance to check it.



Thank you.

Pavel Afremov.


On 11/6/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


Alexei,
  The1363 submission added  functionality for lazy exception support, for
exceptions in the VM code. exn_raise_by_name_internal was such a function.
This may not be bug free ( as is true of any code ) and we need to check
out
2070. I will take a look, as should Pavel.
  I think that while committing 1363, StackTest failed and there were
other
asserts, which Geir disabled to not block the large submission. This is
not
really anything to do with lazy exceptions. This is an issue where parts
of
the main thread's stack virtual memory are unmapped on Linux. I later
added
a fix for this. The two issues are orthogonal to each other.

Rana



On 11/5/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
>
> Rana, Pavel (Afremov), All,
>
> Geir's comment on r443504 (fix for
> http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> bit support, JVMTI improvements) reads:
>
> > 1) Stack overflow exception stuff is broken.  I had to remove the
> assert
> >in signals_ia32.cpp line 336.  Rana knows and will look.  I also
> >disabled the StackTest.
>
> I have noticed that the patch added a new function
> exn_raise_by_name_internal which fails on the first invocation checking
> an assertion about thread state, see
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> crashes DRLVM.
>
> I also have noticed that this function is called to create
> java.lang.StackOverflowError.
>
> Could you help me to understand the current status of the problem?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-Original Message-
> >From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, October 18, 2006 4:27 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
> >fixed
> >
> >I fixed the StackOverflow functionality problem by going back and
> mapping
> >all pages ( guard, alternate stack ) meticulously before trying to
> protect
> >them. I think we should have done this in the first place.  I also
> cleaned
> >up the previous initialization workarounds and asserts Geir and I had
> >discussed on the JIRA. The Stacktest and all other stack related tests
> now
> >pass.
> >
> >I'll submit the patch against 1786 in the next few hours after running
> >acceptance tests.
> >
> >Rana
> >
> >
> >
> >> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> >
> >> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >> > >
> >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> >> > > >> I tried to put some back.  StackTest still doesn't work.  It's
> >hard
> >> > > to
> >> > > >> believe...   so I gave up and just kept going :)
> >> > >
> >> > > >I wonder if the test or the implementation are wrong. Maybe
> someone
> >> > > who added
> >> > > >the test initially could know the answer.
> >> >
> >> >
> >> >
> >> >  There is nothing wrong with the stacktest test itself. The
> >> > > implementation is not quite 100%complete( I think ), but has
> enough
> >> > > functionality and the test passes on Windows. On Linux, it fails.
> I
> >am not
> >> > > sure if this is a regression, or if this ever worked. There is a
> JIRA
> >issue
> >> > > 1786. In summary, memory protection setup for the guard page
> fails on
> >the
> >> > > main thread(only). So the guard does not work and the overflow is
> not
> >> > > detected.
> >> >
> >> >
> >> >mprotect fails with an ENOMEM which is either a mapping failure
> or a
> >> > kernel failure. mprotect() has some known flakiness it seems, as
> per
> >> > literature.
> >> >
> >> >   The basic implementation on Linux is sound. There are secondary
> >design
> >> > issues,but we can only get to them later after we have figured out
> why
> >the
> >> > guard setup fails on the main thread.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >>
> >>
> >>
> >>
> >>
>

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

[Pavel Afremov]

Hello.

Could you be so kind to check
*HARMONY-2018*<https://issues.apache.org/jira/browse/HARMONY-2018>
before start fixing and discussing this bug,  please?

I reported it and provided a fix a week ago.



Thanks.

Pavel Afremov.

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


Rana, Pavel (Afremov), All,

Geir's comment on r443504 (fix for
http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
bit support, JVMTI improvements) reads:

> 1) Stack overflow exception stuff is broken.  I had to remove the
assert
>in signals_ia32.cpp line 336.  Rana knows and will look.  I also
>disabled the StackTest.

I have noticed that the patch added a new function
exn_raise_by_name_internal which fails on the first invocation checking
an assertion about thread state, see
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
crashes DRLVM.

I also have noticed that this function is called to create
java.lang.StackOverflowError.

Could you help me to understand the current status of the problem?

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>I fixed the StackOverflow functionality problem by going back and
mapping
>all pages ( guard, alternate stack ) meticulously before trying to
protect
>them. I think we should have done this in the first place.  I also
cleaned
>up the previous initialization workarounds and asserts Geir and I had
>discussed on the JIRA. The Stacktest and all other stack related tests
now
>pass.
>
>I'll submit the patch against 1786 in the next few hours after running
>acceptance tests.
>
>Rana
>
>
>
>> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> > > >> I tried to put some back.  StackTest still doesn't work.  It's
>hard
>> > > to
>> > > >> believe...   so I gave up and just kept going :)
>> > >
>> > > >I wonder if the test or the implementation are wrong. Maybe
someone
>> > > who added
>> > > >the test initially could know the answer.
>> >
>> >
>> >
>> >  There is nothing wrong with the stacktest test itself. The
>> > > implementation is not quite 100%complete( I think ), but has
enough
>> > > functionality and the test passes on Windows. On Linux, it fails.
I
>am not
>> > > sure if this is a regression, or if this ever worked. There is a
JIRA
>issue
>> > > 1786. In summary, memory protection setup for the guard page
fails on
>the
>> > > main thread(only). So the guard does not work and the overflow is
not
>> > > detected.
>> >
>> >
>> >mprotect fails with an ENOMEM which is either a mapping failure
or a
>> > kernel failure. mprotect() has some known flakiness it seems, as
per
>> > literature.
>> >
>> >   The basic implementation on Linux is sound. There are secondary
>design
>> > issues,but we can only get to them later after we have figured out
why
>the
>> > guard setup fails on the main thread.
>> >
>> >
>> >
>> >
>>
>
>>
>>
>>
>>
>>

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

[Rana Dasgupta]

Alexei,
  The1363 submission added  functionality for lazy exception support, for
exceptions in the VM code. exn_raise_by_name_internal was such a function.
This may not be bug free ( as is true of any code ) and we need to check out
2070. I will take a look, as should Pavel.
  I think that while committing 1363, StackTest failed and there were other
asserts, which Geir disabled to not block the large submission. This is not
really anything to do with lazy exceptions. This is an issue where parts of
the main thread's stack virtual memory are unmapped on Linux. I later added
a fix for this. The two issues are orthogonal to each other.

Rana



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


Rana, Pavel (Afremov), All,

Geir's comment on r443504 (fix for
http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
bit support, JVMTI improvements) reads:

> 1) Stack overflow exception stuff is broken.  I had to remove the
assert
>in signals_ia32.cpp line 336.  Rana knows and will look.  I also
>disabled the StackTest.

I have noticed that the patch added a new function
exn_raise_by_name_internal which fails on the first invocation checking
an assertion about thread state, see
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
crashes DRLVM.

I also have noticed that this function is called to create
java.lang.StackOverflowError.

Could you help me to understand the current status of the problem?

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>I fixed the StackOverflow functionality problem by going back and
mapping
>all pages ( guard, alternate stack ) meticulously before trying to
protect
>them. I think we should have done this in the first place.  I also
cleaned
>up the previous initialization workarounds and asserts Geir and I had
>discussed on the JIRA. The Stacktest and all other stack related tests
now
>pass.
>
>I'll submit the patch against 1786 in the next few hours after running
>acceptance tests.
>
>Rana
>
>
>
>> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> > > >> I tried to put some back.  StackTest still doesn't work.  It's
>hard
>> > > to
>> > > >> believe...   so I gave up and just kept going :)
>> > >
>> > > >I wonder if the test or the implementation are wrong. Maybe
someone
>> > > who added
>> > > >the test initially could know the answer.
>> >
>> >
>> >
>> >  There is nothing wrong with the stacktest test itself. The
>> > > implementation is not quite 100%complete( I think ), but has
enough
>> > > functionality and the test passes on Windows. On Linux, it fails.
I
>am not
>> > > sure if this is a regression, or if this ever worked. There is a
JIRA
>issue
>> > > 1786. In summary, memory protection setup for the guard page
fails on
>the
>> > > main thread(only). So the guard does not work and the overflow is
not
>> > > detected.
>> >
>> >
>> >mprotect fails with an ENOMEM which is either a mapping failure
or a
>> > kernel failure. mprotect() has some known flakiness it seems, as
per
>> > literature.
>> >
>> >   The basic implementation on Linux is sound. There are secondary
>design
>> > issues,but we can only get to them later after we have figured out
why
>the
>> > guard setup fails on the main thread.
>> >
>> >
>> >
>> >
>>
>
>>
>>
>>
>>
>>

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

[Fedotov, Alexei A]

Rana, Pavel (Afremov), All,

Geir's comment on r443504 (fix for
http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
bit support, JVMTI improvements) reads:

> 1) Stack overflow exception stuff is broken.  I had to remove the
assert
>in signals_ia32.cpp line 336.  Rana knows and will look.  I also
>disabled the StackTest.

I have noticed that the patch added a new function
exn_raise_by_name_internal which fails on the first invocation checking
an assertion about thread state, see 
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
crashes DRLVM.

I also have noticed that this function is called to create
java.lang.StackOverflowError. 

Could you help me to understand the current status of the problem?

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>I fixed the StackOverflow functionality problem by going back and
mapping
>all pages ( guard, alternate stack ) meticulously before trying to
protect
>them. I think we should have done this in the first place.  I also
cleaned
>up the previous initialization workarounds and asserts Geir and I had
>discussed on the JIRA. The Stacktest and all other stack related tests
now
>pass.
>
>I'll submit the patch against 1786 in the next few hours after running
>acceptance tests.
>
>Rana
>
>
>
>> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> > > >> I tried to put some back.  StackTest still doesn't work.  It's
>hard
>> > > to
>> > > >> believe...   so I gave up and just kept going :)
>> > >
>> > > >I wonder if the test or the implementation are wrong. Maybe
someone
>> > > who added
>> > > >the test initially could know the answer.
>> >
>> >
>> >
>> >  There is nothing wrong with the stacktest test itself. The
>> > > implementation is not quite 100%complete( I think ), but has
enough
>> > > functionality and the test passes on Windows. On Linux, it fails.
I
>am not
>> > > sure if this is a regression, or if this ever worked. There is a
JIRA
>issue
>> > > 1786. In summary, memory protection setup for the guard page
fails on
>the
>> > > main thread(only). So the guard does not work and the overflow is
not
>> > > detected.
>> >
>> >
>> >mprotect fails with an ENOMEM which is either a mapping failure
or a
>> > kernel failure. mprotect() has some known flakiness it seems, as
per
>> > literature.
>> >
>> >   The basic implementation on Linux is sound. There are secondary
>design
>> > issues,but we can only get to them later after we have figured out
why
>the
>> > guard setup fails on the main thread.
>> >
>> >
>> >
>> >
>>
>
>>
>>
>>
>>
>>

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] [testing] Excluding commit tests until the problem is fixed

[Geir Magnusson Jr.]

w000t!

What init workarounds?


Rana Dasgupta wrote:

I fixed the StackOverflow functionality problem by going back and mapping
all pages ( guard, alternate stack ) meticulously before trying to protect
them. I think we should have done this in the first place.  I also cleaned
up the previous initialization workarounds and asserts Geir and I had
discussed on the JIRA. The Stacktest and all other stack related tests now
pass.

I'll submit the patch against 1786 in the next few hours after running
acceptance tests.

Rana




On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >
> > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> > >> I tried to put some back.  StackTest still doesn't work.  It's 
hard

> > to
> > >> believe...   so I gave up and just kept going :)
> >
> > >I wonder if the test or the implementation are wrong. Maybe someone
> > who added
> > >the test initially could know the answer.
>
>
>
>  There is nothing wrong with the stacktest test itself. The
> > implementation is not quite 100%complete( I think ), but has enough
> > functionality and the test passes on Windows. On Linux, it fails. 
I am not
> > sure if this is a regression, or if this ever worked. There is a 
JIRA issue
> > 1786. In summary, memory protection setup for the guard page fails 
on the

> > main thread(only). So the guard does not work and the overflow is not
> > detected.
>
>
>mprotect fails with an ENOMEM which is either a mapping failure or a
> kernel failure. mprotect() has some known flakiness it seems, as per
> literature.
>
>   The basic implementation on Linux is sound. There are secondary 
design
> issues,but we can only get to them later after we have figured out 
why the

> guard setup fails on the main thread.
>
>
>
>













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

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

[Rana Dasgupta]

I fixed the StackOverflow functionality problem by going back and mapping
all pages ( guard, alternate stack ) meticulously before trying to protect
them. I think we should have done this in the first place.  I also cleaned
up the previous initialization workarounds and asserts Geir and I had
discussed on the JIRA. The Stacktest and all other stack related tests now
pass.

I'll submit the patch against 1786 in the next few hours after running
acceptance tests.

Rana




On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >
> > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> > >> I tried to put some back.  StackTest still doesn't work.  It's hard
> > to
> > >> believe...   so I gave up and just kept going :)
> >
> > >I wonder if the test or the implementation are wrong. Maybe someone
> > who added
> > >the test initially could know the answer.
>
>
>
>  There is nothing wrong with the stacktest test itself. The
> > implementation is not quite 100%complete( I think ), but has enough
> > functionality and the test passes on Windows. On Linux, it fails. I am not
> > sure if this is a regression, or if this ever worked. There is a JIRA issue
> > 1786. In summary, memory protection setup for the guard page fails on the
> > main thread(only). So the guard does not work and the overflow is not
> > detected.
>
>
>mprotect fails with an ENOMEM which is either a mapping failure or a
> kernel failure. mprotect() has some known flakiness it seems, as per
> literature.
>
>   The basic implementation on Linux is sound. There are secondary design
> issues,but we can only get to them later after we have figured out why the
> guard setup fails on the main thread.
>
>
>
>

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

[Gregory Shimansky]

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.

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

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] [testing] Excluding commit tests until the problem is fixed

[Gregory Shimansky]

2006/10/17, Alexey Varlamov <[EMAIL PROTECTED]>:


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

It would be nice if Gregory confirmed that Win XP and Win 2003
machines which he compared have identical HW - this might be multicore
vs single-CPU (HT does not count) specific rather than OS?
Gregory?



The ones that I have are different. XP is on laptop with a single CPU, the
server is on P4 with HT enabled.

Actually it wasn't me who discovered the problem on 2003 server, it was
Elena who created HARMONY-1669.

--
Gregory Shimansky, Intel Middleware Products Division

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

[Alexey Varlamov]

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


It would be nice if Gregory confirmed that Win XP and Win 2003
machines which he compared have identical HW - this might be multicore
vs single-CPU (HT does not count) specific rather than OS?
Gregory?



geir

>
> Thanks,
> Rana
>

-
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]

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

[Geir Magnusson Jr.]

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



Thanks,
Rana



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

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

[Rana Dasgupta]

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.

Thanks,
Rana

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

[Geir Magnusson Jr.]

So since I don't have Win 2003, I gotta just commit and let someone else 
test?


Any committer have win 2003?

Fedotov, Alexei A wrote:
Sorry for my English - 


http://issues.apache.org/jira/browse/HARMONY-1669
Artem told this patch fixes a deadlock on Windows.

I haven't tried the fix. As far as I understand we put SuspendThread()
check and ResumeThread() action under one critical section when trying
to flush memory. It's ok not to risk the integrity of the whole
operation.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 1:30 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] [testing] Excluding commit tests until the problem

is

fixed



Fedotov, Alexei A wrote:

Hello Gregory,

I'm ok to exclude the tests. From the other side I believe we can
achieve a fair progress against deadlocks just by applying patches
http://issues.apache.org/jira/browse/HARMONY-1741 (understood),
http://issues.apache.org/jira/browse/HARMONY-1823 (tried).

Maybe - i tried 1823 and didnt' see the failure.  I'll look at both

again.

There is also a Windows-specific patch at
http://issues.apache.org/jira/browse/HARMONY-1669
which can result in deadlock, though I haven't tried it myself yet.

Do you mean the fix results in deadlock?  or the fix fixes the

deadlock?

geir


With best regards,
Alexei Fedotov,
Intel Java & XML Engineering


-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 12:23 AM
To: Fedotov, Alexei A
Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov;

harmony-

[EMAIL PROTECTED]
Subject: Re: [drlvm] [testing] Excluding commit tests until the

problem

is

fixed

On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote:

We have mighty guys on this list. Why cannot we just fix these

tests

instead of excluding them?

Because a test like gc.LOS hangs on windows for a month or more as

far

as I

remember. AFAIK (excuse me if I missed something, I've caught up

with

emails
skipping some) the problems come from APR implementation on windows,

but I

am
not sure if there is a patch for APR to fix the problem.

I hoped for a quick fix too because I don't like tests exclusion

myself.

But
when the problem proves to be hard to solve it is better to put the

test

aside and have clean test runs to make development easier for

everyone.

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.

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 te

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

[Rana Dasgupta]

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


On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> I tried to put some back.  StackTest still doesn't work.  It's hard to
>> believe...   so I gave up and just kept going :)

>I wonder if the test or the implementation are wrong. Maybe someone who
added
>the test initially could know the answer.




There is nothing wrong with the stacktest test itself. The implementation

is not quite 100%complete( I think ), but has enough functionality and the
test passes on Windows. On Linux, it fails. I am not sure if this is a
regression, or if this ever worked. There is a JIRA issue 1786. In summary,
memory protection setup for the guard page fails on the main thread(only).
So the guard does not work and the overflow is not detected.



  mprotect fails with an ENOMEM which is either a mapping failure or a
kernel failure. mprotect() has some known flakiness it seems, as per
literature.

 The basic implementation on Linux is sound. There are secondary design
issues,but we can only get to them later after we have figured out why the
guard setup fails on the main thread.

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

[Gregory Shimansky]

On Tuesday 17 October 2006 01:53 Fedotov, Alexei A wrote:
> Sorry for my English -
>
> http://issues.apache.org/jira/browse/HARMONY-1669
> Artem told this patch fixes a deadlock on Windows.
>
> I haven't tried the fix. As far as I understand we put SuspendThread()
> check and ResumeThread() action under one critical section when trying
> to flush memory. It's ok not to risk the integrity of the whole
> operation.

From the JIRA comments it must be something different. It is a race condition 
rather than a dead lock fix.

Also gc.LOS hangs on Windows XP for me. It works just fine on Windows 2003 
Server SP1. There is some difference between these two win32 kernels and 
we've had fixes for XP while 2003 server worked (actually Windows 2003 Server 
SP1, without server pack it worked like XP, it hung) well. The example is 
HARMONY-1541.

So it is better to determine windows kernel clearly. XP, 2003 or 2003 SP1. 
From the JIRA comments it looks like a fix for 2003 or 2003 SP1. On XP gc.LOS 
still doesn't work.

-- 
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]

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

[Fedotov, Alexei A]

Sorry for my English - 

http://issues.apache.org/jira/browse/HARMONY-1669
Artem told this patch fixes a deadlock on Windows.

I haven't tried the fix. As far as I understand we put SuspendThread()
check and ResumeThread() action under one critical section when trying
to flush memory. It's ok not to risk the integrity of the whole
operation.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 17, 2006 1:30 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>
>
>Fedotov, Alexei A wrote:
>> Hello Gregory,
>>
>> I'm ok to exclude the tests. From the other side I believe we can
>> achieve a fair progress against deadlocks just by applying patches
>> http://issues.apache.org/jira/browse/HARMONY-1741 (understood),
>> http://issues.apache.org/jira/browse/HARMONY-1823 (tried).
>
>Maybe - i tried 1823 and didnt' see the failure.  I'll look at both
again.
>
>>
>> There is also a Windows-specific patch at
>> http://issues.apache.org/jira/browse/HARMONY-1669
>> which can result in deadlock, though I haven't tried it myself yet.
>
>Do you mean the fix results in deadlock?  or the fix fixes the
deadlock?
>
>geir
>
>>
>> With best regards,
>> Alexei Fedotov,
>> Intel Java & XML Engineering
>>
>>> -Original Message-
>>> From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, October 17, 2006 12:23 AM
>>> To: Fedotov, Alexei A
>>> Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov;
>> harmony-
>>> [EMAIL PROTECTED]
>>> Subject: Re: [drlvm] [testing] Excluding commit tests until the
problem
>> is
>>> fixed
>>>
>>> On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote:
>>>> We have mighty guys on this list. Why cannot we just fix these
tests
>>>> instead of excluding them?
>>> Because a test like gc.LOS hangs on windows for a month or more as
far
>> as I
>>> remember. AFAIK (excuse me if I missed something, I've caught up
with
>>> emails
>>> skipping some) the problems come from APR implementation on windows,
>> but I
>>> am
>>> not sure if there is a patch for APR to fix the problem.
>>>
>>> I hoped for a quick fix too because I don't like tests exclusion
>> myself.
>>> But
>>> when the problem proves to be hard to solve it is better to put the
>> test
>>> aside and have clean test runs to make development easier for
everyone.
>>>
>>>> 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.
>>>> 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.
>>>>>

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

[Geir Magnusson Jr.]

Fedotov, Alexei A wrote:

Hello Gregory,

I'm ok to exclude the tests. From the other side I believe we can
achieve a fair progress against deadlocks just by applying patches
http://issues.apache.org/jira/browse/HARMONY-1741 (understood),
http://issues.apache.org/jira/browse/HARMONY-1823 (tried).


Maybe - i tried 1823 and didnt' see the failure.  I'll look at both again.



There is also a Windows-specific patch at
http://issues.apache.org/jira/browse/HARMONY-1669
which can result in deadlock, though I haven't tried it myself yet.


Do you mean the fix results in deadlock?  or the fix fixes the deadlock?

geir



With best regards,
Alexei Fedotov,
Intel Java & XML Engineering


-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 12:23 AM
To: Fedotov, Alexei A
Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov;

harmony-

[EMAIL PROTECTED]
Subject: Re: [drlvm] [testing] Excluding commit tests until the problem

is

fixed

On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote:

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

Because a test like gc.LOS hangs on windows for a month or more as far

as I

remember. AFAIK (excuse me if I missed something, I've caught up with
emails
skipping some) the problems come from APR implementation on windows,

but I

am
not sure if there is a patch for APR to fix the problem.

I hoped for a quick fix too because I don't like tests exclusion

myself.

But
when the problem proves to be hard to solve it is better to put the

test

aside and have clean test runs to make development easier for everyone.


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.

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]

--
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]

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

[Fedotov, Alexei A]

Hello Gregory,

I'm ok to exclude the tests. From the other side I believe we can
achieve a fair progress against deadlocks just by applying patches
http://issues.apache.org/jira/browse/HARMONY-1741 (understood),
http://issues.apache.org/jira/browse/HARMONY-1823 (tried).

There is also a Windows-specific patch at
http://issues.apache.org/jira/browse/HARMONY-1669
which can result in deadlock, though I haven't tried it myself yet.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 17, 2006 12:23 AM
>To: Fedotov, Alexei A
>Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov;
harmony-
>[EMAIL PROTECTED]
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote:
>> We have mighty guys on this list. Why cannot we just fix these tests
>> instead of excluding them?
>
>Because a test like gc.LOS hangs on windows for a month or more as far
as I
>remember. AFAIK (excuse me if I missed something, I've caught up with
>emails
>skipping some) the problems come from APR implementation on windows,
but I
>am
>not sure if there is a patch for APR to fix the problem.
>
>I hoped for a quick fix too because I don't like tests exclusion
myself.
>But
>when the problem proves to be hard to solve it is better to put the
test
>aside and have clean test runs to make development easier for everyone.
>
>> 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.
>>
>> 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
>> >

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

[Gregory Shimansky]

On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote:
> We have mighty guys on this list. Why cannot we just fix these tests
> instead of excluding them?

Because a test like gc.LOS hangs on windows for a month or more as far as I 
remember. AFAIK (excuse me if I missed something, I've caught up with emails 
skipping some) the problems come from APR implementation on windows, but I am 
not sure if there is a patch for APR to fix the problem.

I hoped for a quick fix too because I don't like tests exclusion myself. But 
when the problem proves to be hard to solve it is better to put the test 
aside and have clean test runs to make development easier for everyone.

> 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.
>
> 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]

-- 
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]

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

[Geir Magnusson Jr.]

+1 - but I'm going to still exclude tests so we can move forward :)

Fedotov, Alexei A 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.

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]



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

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

[Gregory Shimansky]

On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> 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.

I never said you do. It is just an inconvenience for other people too, we also 
try to check a patch before submission to JIRA.

> > 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 :)

I wonder if the test or the implementation are wrong. Maybe someone who added 
the test initially could know the answer.

-- 
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]

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

[Fedotov, Alexei A]

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.

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]

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

[Geir Magnusson Jr.]

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]

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

[Gregory Shimansky]

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.

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?

-- 
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]