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-list
 !-- exclude only particular tests --
 class name=org.apache.harmony.luni.test.java.io.MyTest
   test name=testConstructor11/
   test name=testMyMethodObjectObjectString_HY1234/
 /class
 !-- exclude all tests --
 class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list

exclude.linux.drlvm.xml:
---
exclude-list
 class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
   test name=testLinuxHang_my/
 /class
/exclude-list

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*http://issues.apache.org/jira/browse/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 

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-list
!-- exclude only particular tests --
class name=org.apache.harmony.luni.test.java.io.MyTest
   test name=testConstructor11/
   test name=testMyMethodObjectObjectString_HY1234/
/class
!-- exclude all tests --
class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list

exclude.linux.drlvm.xml:
---
exclude-list
class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
   test name=testLinuxHang_my/
/class
/exclude-list

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*http://issues.apache.org/jira/browse/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
   

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-list
 !-- exclude only particular tests --
 class name=org.apache.harmony.luni.test.java.io.MyTest
   test name=testConstructor11/
   test name=testMyMethodObjectObjectString_HY1234/
 /class
 !-- exclude all tests --
 class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list

exclude.linux.drlvm.xml:
---
exclude-list
 class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
   test name=testLinuxHang_my/
 /class
/exclude-list

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*http://issues.apache.org/jira/browse/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 

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-list
 !-- exclude only particular tests --
 class name=org.apache.harmony.luni.test.java.io.MyTest
   test name=testConstructor11/
   test name=testMyMethodObjectObjectString_HY1234/
 /class
 !-- exclude all tests --
 class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list

exclude.linux.drlvm.xml:
---
exclude-list
 class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
   test name=testLinuxHang_my/
 /class
/exclude-list

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*http://issues.apache.org/jira/browse/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 

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*http://issues.apache.org/jira/browse/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

 property name=hy.test.vm.name value=ibm /

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

[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* 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.
  
  
  
 
 

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

As part of solution for this issue the
*HARMONY-2197*http://issues.apache.org/jira/browse/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 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*http://issues.apache.org/jira/browse/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]

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*http://issues.apache.org/jira/browse/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*http://issues.apache.org/jira/browse/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

[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*http://issues.apache.org/jira/browse/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

[Tim Ellison]

Vladimir Ivanov wrote:
 As part of solution for this issue the
 *HARMONY-2197*http://issues.apache.org/jira/browse/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

  property name=hy.test.vm.name value=ibm /

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

[Vladimir Ivanov]

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


Vladimir Ivanov wrote:
 As part of solution for this issue the
 *HARMONY-2197*http://issues.apache.org/jira/browse/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

property name=hy.test.vm.name value=ibm /

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

[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* 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.

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

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

[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

[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* 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.

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

[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

[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

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

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

[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

[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

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

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

[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

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

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

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]

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

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

[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

[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 test runs?

I tried to put some back.  StackTest still doesn't work.  It's

hard

to

believe...   so I gave up and just

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

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]