You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by tatyana doubtsova <ta...@gmail.com> on 2006/11/21 15:06:37 UTC
[drlvm][classlib unit tests] iterative runs
Hello,
I've run classlib unit tests on Win XP in Other VM mode 50 times for each
module in order to reveal sporadic failures.
The script is
#!sh
cat modulesList | while read moduleName; do
A=0
while [ "$A" -lt "50" ]; do
echo ITERATION $A
ant -
Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
-Dbuild.module=$moduleName -
Dhy.test.forkmode=perTest \
test 2>&1 | tee log_${moduleName}_${A}.txt
cp -rf build/test_report build/test_report.${moduleName}_${A}
A=`expr $A + 1`
done
done
$ cat moduleList
accessibility
archive
auth
awt
beans
crypto
instrument
jndi
lang-management
logging
luni
math
nio
nio_char
prefs
print
regex
rmi
security
sound
sql
swing
text
tools
x-net
I've observed the following failures on svn=r476124
*Module*
*Test*
*Number of failures*
*issue*
luni
org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
50 out of 50
1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
luni
tests.api.java.net.InetAddressTest
50 out of 50
Test was eliminated from repository after Novenber,17
prefs
org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
50 out of 50
1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
swing
javax.swing.text.WrappedPlainView_SimpleTest
1 time out of 50
1)
swing
javax.swing.SpinnerDateModelTest
35 times out of 50
2)
1). Eror
Timeout occurred
junit.framework.AssertionFailedError: Timeout occurred
2). Failure
expected:<0> but was:<7>
junit.framework.AssertionFailedError: expected:<0> but was:<7> at
javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
SpinnerDateModelTest.java:59) at
java.lang.reflect.VMReflection.invokeMethod(Native
Method) at javax.swing.BasicSwingTestCase.runBareSuper(
BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl(
BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not reproduced
during this test run
I can't reproduce 1) and 2) today on svn = r477507
I've excluded failed tests and restarted multiple test run on Win XP in
order to make sure there is no other sporadic failures.
Also I'm going to start the multiple classlib tests run on SUSE 9
To extract the results I've used commands:
cd classlib/trunk/buid
# find errors
find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" " {} \; >
ERRORS
# find failures
find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
failures=\"[1-9]*\"" {} \; > FAILURES
find . -type f -size 0 | grep *.xml > ZERO_LENGTH
Also I've compared the number of files in test_report directories:
#!sh
cat modulesList | while read moduleName; do
echo $moduleName
A=1
while [ "$A" -lt "51" ]; do
L=`ls -1 build/test_report.${moduleName}_${A} | grep xml | wc
-l`
echo build/test_report.${moduleName}_${A} $L >>
test_report_length
A=`expr $A + 1`
done
done
Thanks,
Tanya
Re: [drlvm][classlib unit tests] iterative runs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
tatyana doubtsova wrote:
> I'm not sure the iterative runs should be incorporated in CC for 2 reasons:
> 1. Those runs are time consuming.
So? They are important!
Oh, note that I said "possible" - I don't mean that everyone running the
CC framework should have to run them - I mean I can setup a second
machine and just run that target, and get all the goodness of the CC
framework for free.
> 2. ant is not acceptable to organize loops.
There must be a way to fix this.
geir
>
> Thanks,
> Tanya
>
> On 11/24/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> This is incredibly useful. Thanks. We need to incorporate this as a
>> possible target in CC.
>>
>> geir
>>
>> tatyana doubtsova wrote:
>> > I created lists of intermittent unit tests failures on Win XP in
>> perTest
>> > mode:
>> > http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
>> > http://issues.apache.org/jira/browse/HARMONY-2284 - security module
>> >
>> > Could anybody take a look at it?
>> >
>> > I did not observe intermittent failures in other modules on Win XP so
>> far.
>> > I'm going to continue iterative classlib tests runs.
>> >
>> > Thanks,
>> > Tanya
>> >
>> > On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
>> >
>> >> Tatiana,
>> >> That's great! Feel free to file JIRA issues about new problems.
>> >>
>> >> This is quite interesting that you haven't discovered
>> >> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
>> >> failure using effectively the same revision as I. This makes me think
>> >> that my problems can be local to my computer.
>> >>
>> >> --
>> >> Thank you,
>> >> Alexei
>> >>
>> >> On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > I've run classlib unit tests on Win XP in Other VM mode 50 times for
>> >> each
>> >> > module in order to reveal sporadic failures.
>> >> >
>> >> >
>> >> >
>> >> > The script is
>> >> >
>> >> >
>> >> >
>> >> > #!sh
>> >> >
>> >> > cat modulesList | while read moduleName; do
>> >> >
>> >> > A=0
>> >> >
>> >> > while [ "$A" -lt "50" ]; do
>> >> >
>> >> > echo ITERATION $A
>> >> >
>> >> > ant -
>> >> >
>> >>
>> Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
>>
>> >>
>> >> >
>> >> > -Dbuild.module=$moduleName -
>> >> > Dhy.test.forkmode=perTest \
>> >> >
>> >> > test 2>&1 | tee log_${moduleName}_${A}.txt
>> >> >
>> >> > cp -rf build/test_report
>> >> build/test_report.${moduleName}_${A}
>> >> >
>> >> > A=`expr $A + 1`
>> >> >
>> >> > done
>> >> >
>> >> > done
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > $ cat moduleList
>> >> >
>> >> >
>> >> >
>> >> > accessibility
>> >> >
>> >> > archive
>> >> >
>> >> > auth
>> >> >
>> >> > awt
>> >> >
>> >> > beans
>> >> >
>> >> > crypto
>> >> >
>> >> > instrument
>> >> >
>> >> > jndi
>> >> >
>> >> > lang-management
>> >> >
>> >> > logging
>> >> >
>> >> > luni
>> >> >
>> >> > math
>> >> >
>> >> > nio
>> >> >
>> >> > nio_char
>> >> >
>> >> > prefs
>> >> >
>> >> > print
>> >> >
>> >> > regex
>> >> >
>> >> > rmi
>> >> >
>> >> > security
>> >> >
>> >> > sound
>> >> >
>> >> > sql
>> >> >
>> >> > swing
>> >> >
>> >> > text
>> >> >
>> >> > tools
>> >> >
>> >> > x-net
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > I've observed the following failures on svn=r476124
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > *Module*
>> >> >
>> >> > *Test*
>> >> >
>> >> > *Number of failures*
>> >> >
>> >> > *issue*
>> >> >
>> >> > luni
>> >> >
>> >> >
>> >>
>> org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
>>
>> >>
>> >> >
>> >> > 50 out of 50
>> >> >
>> >> > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
>> >> >
>> >> > luni
>> >> >
>> >> > tests.api.java.net.InetAddressTest
>> >> >
>> >> > 50 out of 50
>> >> >
>> >> > Test was eliminated from repository after Novenber,17
>> >> >
>> >> > prefs
>> >> >
>> >> > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
>> >> >
>> >> > 50 out of 50
>> >> >
>> >> > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
>> >> >
>> >> > swing
>> >> >
>> >> > javax.swing.text.WrappedPlainView_SimpleTest
>> >> >
>> >> > 1 time out of 50
>> >> >
>> >> > 1)
>> >> >
>> >> > swing
>> >> >
>> >> > javax.swing.SpinnerDateModelTest
>> >> >
>> >> > 35 times out of 50
>> >> >
>> >> > 2)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > 1). Eror
>> >> >
>> >> > Timeout occurred
>> >> >
>> >> > junit.framework.AssertionFailedError: Timeout occurred
>> >> >
>> >> >
>> >> >
>> >> > 2). Failure
>> >> >
>> >> > expected:<0> but was:<7>
>> >> >
>> >> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at
>> >> > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
>> >> > SpinnerDateModelTest.java:59) at
>> >> > java.lang.reflect.VMReflection.invokeMethod(Native
>> >> > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
>> >> > BasicSwingTestCase.java) at
>> javax.swing.BasicSwingTestCase.runBareImpl(
>> >> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
>> >> > BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
>> >> >
>> >> >
>> >> >
>> >> > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
>> >> reproduced
>> >> > during this test run
>> >> >
>> >> >
>> >> >
>> >> > I can't reproduce 1) and 2) today on svn = r477507
>> >> >
>> >> >
>> >> >
>> >> > I've excluded failed tests and restarted multiple test run on Win XP
>> in
>> >> > order to make sure there is no other sporadic failures.
>> >> >
>> >> > Also I'm going to start the multiple classlib tests run on SUSE 9
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > To extract the results I've used commands:
>> >> >
>> >> > cd classlib/trunk/buid
>> >> >
>> >> > # find errors
>> >> >
>> >> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" "
>> {}
>> >> \; >
>> >> > ERRORS
>> >> >
>> >> > # find failures
>> >> >
>> >> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
>> >> > failures=\"[1-9]*\"" {} \; > FAILURES
>> >> >
>> >> > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
>> >> >
>> >> >
>> >> >
>> >> > Also I've compared the number of files in test_report directories:
>> >> >
>> >> > #!sh
>> >> >
>> >> > cat modulesList | while read moduleName; do
>> >> >
>> >> > echo $moduleName
>> >> >
>> >> > A=1
>> >> >
>> >> > while [ "$A" -lt "51" ]; do
>> >> >
>> >> > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml
>> >> | wc
>> >> > -l`
>> >> >
>> >> > echo build/test_report.${moduleName}_${A} $L >>
>> >> > test_report_length
>> >> >
>> >> > A=`expr $A + 1`
>> >> >
>> >> > done
>> >> > done
>> >> >
>> >> > Thanks,
>> >> > Tanya
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by tatyana doubtsova <ta...@gmail.com>.
I'm not sure the iterative runs should be incorporated in CC for 2 reasons:
1. Those runs are time consuming.
2. ant is not acceptable to organize loops.
Thanks,
Tanya
On 11/24/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> This is incredibly useful. Thanks. We need to incorporate this as a
> possible target in CC.
>
> geir
>
> tatyana doubtsova wrote:
> > I created lists of intermittent unit tests failures on Win XP in perTest
> > mode:
> > http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> > http://issues.apache.org/jira/browse/HARMONY-2284 - security module
> >
> > Could anybody take a look at it?
> >
> > I did not observe intermittent failures in other modules on Win XP so
> far.
> > I'm going to continue iterative classlib tests runs.
> >
> > Thanks,
> > Tanya
> >
> > On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
> >
> >> Tatiana,
> >> That's great! Feel free to file JIRA issues about new problems.
> >>
> >> This is quite interesting that you haven't discovered
> >> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> >> failure using effectively the same revision as I. This makes me think
> >> that my problems can be local to my computer.
> >>
> >> --
> >> Thank you,
> >> Alexei
> >>
> >> On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> >> each
> >> > module in order to reveal sporadic failures.
> >> >
> >> >
> >> >
> >> > The script is
> >> >
> >> >
> >> >
> >> > #!sh
> >> >
> >> > cat modulesList | while read moduleName; do
> >> >
> >> > A=0
> >> >
> >> > while [ "$A" -lt "50" ]; do
> >> >
> >> > echo ITERATION $A
> >> >
> >> > ant -
> >> >
> >>
> Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> >>
> >> >
> >> > -Dbuild.module=$moduleName -
> >> > Dhy.test.forkmode=perTest \
> >> >
> >> > test 2>&1 | tee log_${moduleName}_${A}.txt
> >> >
> >> > cp -rf build/test_report
> >> build/test_report.${moduleName}_${A}
> >> >
> >> > A=`expr $A + 1`
> >> >
> >> > done
> >> >
> >> > done
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > $ cat moduleList
> >> >
> >> >
> >> >
> >> > accessibility
> >> >
> >> > archive
> >> >
> >> > auth
> >> >
> >> > awt
> >> >
> >> > beans
> >> >
> >> > crypto
> >> >
> >> > instrument
> >> >
> >> > jndi
> >> >
> >> > lang-management
> >> >
> >> > logging
> >> >
> >> > luni
> >> >
> >> > math
> >> >
> >> > nio
> >> >
> >> > nio_char
> >> >
> >> > prefs
> >> >
> >> > print
> >> >
> >> > regex
> >> >
> >> > rmi
> >> >
> >> > security
> >> >
> >> > sound
> >> >
> >> > sql
> >> >
> >> > swing
> >> >
> >> > text
> >> >
> >> > tools
> >> >
> >> > x-net
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > I've observed the following failures on svn=r476124
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > *Module*
> >> >
> >> > *Test*
> >> >
> >> > *Number of failures*
> >> >
> >> > *issue*
> >> >
> >> > luni
> >> >
> >> >
> >>
> org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> >>
> >> >
> >> > 50 out of 50
> >> >
> >> > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> >> >
> >> > luni
> >> >
> >> > tests.api.java.net.InetAddressTest
> >> >
> >> > 50 out of 50
> >> >
> >> > Test was eliminated from repository after Novenber,17
> >> >
> >> > prefs
> >> >
> >> > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> >> >
> >> > 50 out of 50
> >> >
> >> > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
> >> >
> >> > swing
> >> >
> >> > javax.swing.text.WrappedPlainView_SimpleTest
> >> >
> >> > 1 time out of 50
> >> >
> >> > 1)
> >> >
> >> > swing
> >> >
> >> > javax.swing.SpinnerDateModelTest
> >> >
> >> > 35 times out of 50
> >> >
> >> > 2)
> >> >
> >> >
> >> >
> >> >
> >> > 1). Eror
> >> >
> >> > Timeout occurred
> >> >
> >> > junit.framework.AssertionFailedError: Timeout occurred
> >> >
> >> >
> >> >
> >> > 2). Failure
> >> >
> >> > expected:<0> but was:<7>
> >> >
> >> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at
> >> > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
> >> > SpinnerDateModelTest.java:59) at
> >> > java.lang.reflect.VMReflection.invokeMethod(Native
> >> > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> >> > BasicSwingTestCase.java) at
> javax.swing.BasicSwingTestCase.runBareImpl(
> >> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> >> > BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
> >> >
> >> >
> >> >
> >> > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
> >> reproduced
> >> > during this test run
> >> >
> >> >
> >> >
> >> > I can't reproduce 1) and 2) today on svn = r477507
> >> >
> >> >
> >> >
> >> > I've excluded failed tests and restarted multiple test run on Win XP
> in
> >> > order to make sure there is no other sporadic failures.
> >> >
> >> > Also I'm going to start the multiple classlib tests run on SUSE 9
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > To extract the results I've used commands:
> >> >
> >> > cd classlib/trunk/buid
> >> >
> >> > # find errors
> >> >
> >> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" "
> {}
> >> \; >
> >> > ERRORS
> >> >
> >> > # find failures
> >> >
> >> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> >> > failures=\"[1-9]*\"" {} \; > FAILURES
> >> >
> >> > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> >> >
> >> >
> >> >
> >> > Also I've compared the number of files in test_report directories:
> >> >
> >> > #!sh
> >> >
> >> > cat modulesList | while read moduleName; do
> >> >
> >> > echo $moduleName
> >> >
> >> > A=1
> >> >
> >> > while [ "$A" -lt "51" ]; do
> >> >
> >> > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml
> >> | wc
> >> > -l`
> >> >
> >> > echo build/test_report.${moduleName}_${A} $L >>
> >> > test_report_length
> >> >
> >> > A=`expr $A + 1`
> >> >
> >> > done
> >> > done
> >> >
> >> > Thanks,
> >> > Tanya
> >> >
> >> >
> >>
> >
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
This is incredibly useful. Thanks. We need to incorporate this as a
possible target in CC.
geir
tatyana doubtsova wrote:
> I created lists of intermittent unit tests failures on Win XP in perTest
> mode:
> http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> http://issues.apache.org/jira/browse/HARMONY-2284 - security module
>
> Could anybody take a look at it?
>
> I did not observe intermittent failures in other modules on Win XP so far.
> I'm going to continue iterative classlib tests runs.
>
> Thanks,
> Tanya
>
> On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
>
>> Tatiana,
>> That's great! Feel free to file JIRA issues about new problems.
>>
>> This is quite interesting that you haven't discovered
>> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
>> failure using effectively the same revision as I. This makes me think
>> that my problems can be local to my computer.
>>
>> --
>> Thank you,
>> Alexei
>>
>> On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
>> > Hello,
>> >
>> > I've run classlib unit tests on Win XP in Other VM mode 50 times for
>> each
>> > module in order to reveal sporadic failures.
>> >
>> >
>> >
>> > The script is
>> >
>> >
>> >
>> > #!sh
>> >
>> > cat modulesList | while read moduleName; do
>> >
>> > A=0
>> >
>> > while [ "$A" -lt "50" ]; do
>> >
>> > echo ITERATION $A
>> >
>> > ant -
>> >
>> Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
>>
>> >
>> > -Dbuild.module=$moduleName -
>> > Dhy.test.forkmode=perTest \
>> >
>> > test 2>&1 | tee log_${moduleName}_${A}.txt
>> >
>> > cp -rf build/test_report
>> build/test_report.${moduleName}_${A}
>> >
>> > A=`expr $A + 1`
>> >
>> > done
>> >
>> > done
>> >
>> >
>> >
>> >
>> >
>> > $ cat moduleList
>> >
>> >
>> >
>> > accessibility
>> >
>> > archive
>> >
>> > auth
>> >
>> > awt
>> >
>> > beans
>> >
>> > crypto
>> >
>> > instrument
>> >
>> > jndi
>> >
>> > lang-management
>> >
>> > logging
>> >
>> > luni
>> >
>> > math
>> >
>> > nio
>> >
>> > nio_char
>> >
>> > prefs
>> >
>> > print
>> >
>> > regex
>> >
>> > rmi
>> >
>> > security
>> >
>> > sound
>> >
>> > sql
>> >
>> > swing
>> >
>> > text
>> >
>> > tools
>> >
>> > x-net
>> >
>> >
>> >
>> >
>> >
>> > I've observed the following failures on svn=r476124
>> >
>> >
>> >
>> >
>> >
>> > *Module*
>> >
>> > *Test*
>> >
>> > *Number of failures*
>> >
>> > *issue*
>> >
>> > luni
>> >
>> >
>> org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
>>
>> >
>> > 50 out of 50
>> >
>> > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
>> >
>> > luni
>> >
>> > tests.api.java.net.InetAddressTest
>> >
>> > 50 out of 50
>> >
>> > Test was eliminated from repository after Novenber,17
>> >
>> > prefs
>> >
>> > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
>> >
>> > 50 out of 50
>> >
>> > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
>> >
>> > swing
>> >
>> > javax.swing.text.WrappedPlainView_SimpleTest
>> >
>> > 1 time out of 50
>> >
>> > 1)
>> >
>> > swing
>> >
>> > javax.swing.SpinnerDateModelTest
>> >
>> > 35 times out of 50
>> >
>> > 2)
>> >
>> >
>> >
>> >
>> > 1). Eror
>> >
>> > Timeout occurred
>> >
>> > junit.framework.AssertionFailedError: Timeout occurred
>> >
>> >
>> >
>> > 2). Failure
>> >
>> > expected:<0> but was:<7>
>> >
>> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at
>> > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
>> > SpinnerDateModelTest.java:59) at
>> > java.lang.reflect.VMReflection.invokeMethod(Native
>> > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
>> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl(
>> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
>> > BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
>> >
>> >
>> >
>> > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
>> reproduced
>> > during this test run
>> >
>> >
>> >
>> > I can't reproduce 1) and 2) today on svn = r477507
>> >
>> >
>> >
>> > I've excluded failed tests and restarted multiple test run on Win XP in
>> > order to make sure there is no other sporadic failures.
>> >
>> > Also I'm going to start the multiple classlib tests run on SUSE 9
>> >
>> >
>> >
>> >
>> >
>> > To extract the results I've used commands:
>> >
>> > cd classlib/trunk/buid
>> >
>> > # find errors
>> >
>> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" " {}
>> \; >
>> > ERRORS
>> >
>> > # find failures
>> >
>> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
>> > failures=\"[1-9]*\"" {} \; > FAILURES
>> >
>> > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
>> >
>> >
>> >
>> > Also I've compared the number of files in test_report directories:
>> >
>> > #!sh
>> >
>> > cat modulesList | while read moduleName; do
>> >
>> > echo $moduleName
>> >
>> > A=1
>> >
>> > while [ "$A" -lt "51" ]; do
>> >
>> > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml
>> | wc
>> > -l`
>> >
>> > echo build/test_report.${moduleName}_${A} $L >>
>> > test_report_length
>> >
>> > A=`expr $A + 1`
>> >
>> > done
>> > done
>> >
>> > Thanks,
>> > Tanya
>> >
>> >
>>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Alexei Fedotov <al...@gmail.com>.
Tatiana,
Thanks for updating the issue with new failures. I believe it is very
important to have intermittent failures documented.
Next time I would suggest filing a new issue in case when a resolution
provider solves at least a part of the problem. Why?
* The resolution provider is happy to have the issue solved by him.
* All other readers including a resolution provider and committer for
another part of the issue have less items to read and understand.
My best practice is to reopen issues only if a proposed resolution is
not a step in the right direction.
Thank you again for adding information about new intermittent failures
- this is much more valuable than my previous comment.
--
Thank you,
Alexei
On 11/27/06, tatyana doubtsova <ta...@gmail.com> wrote:
> There are intermittent failures in nio module after applying fix to
> http://issues.apache.org/jira/browse/HARMONY-2285. I udated the issue.
>
> Thanks,
> Tanya
>
>
> On 11/24/06, tatyana doubtsova <ta...@gmail.com> wrote:
> >
> > I also created issues regarding intermittent failures on SUSE9:
> > http://issues.apache.org/jira/browse/HARMONY-2315
> > http://issues.apache.org/jira/browse/HARMONY-2307
> >
> > Thanks,
> > Tanya
> >
> > On 11/23/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > >
> > > I created lists of intermittent unit tests failures on Win XP in perTest
> > > mode:
> > > http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> > > http://issues.apache.org/jira/browse/HARMONY-2284 - security module
> > >
> > > Could anybody take a look at it?
> > >
> > > I did not observe intermittent failures in other modules on Win XP so
> > > far.
> > > I'm going to continue iterative classlib tests runs.
> > >
> > > Thanks,
> > > Tanya
> > >
> > > On 11/22/06, Alexei Fedotov <alexei.fedotov@gmail.com > wrote:
> > >
> > > > Tatiana,
> > > > That's great! Feel free to file JIRA issues about new problems.
> > > >
> > > > This is quite interesting that you haven't discovered
> > > > org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > > > failure using effectively the same revision as I. This makes me think
> > > > that my problems can be local to my computer.
> > > >
> > > > --
> > > > Thank you,
> > > > Alexei
> > > >
> > > > On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> > > > each
> > > > > module in order to reveal sporadic failures.
> > > > >
> > > > >
> > > > >
> > > > > The script is
> > > > >
> > > > >
> > > > >
> > > > > #!sh
> > > > >
> > > > > cat modulesList | while read moduleName; do
> > > > >
> > > > > A=0
> > > > >
> > > > > while [ "$A" -lt "50" ]; do
> > > > >
> > > > > echo ITERATION $A
> > > > >
> > > > > ant -
> > > > >
> > > > Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> > > > >
> > > > > -Dbuild.module=$moduleName -
> > > > > Dhy.test.forkmode=perTest \
> > > > >
> > > > > test 2>&1 | tee log_${moduleName}_${A}.txt
> > > > >
> > > > > cp -rf build/test_report
> > > > build/test_report.${moduleName}_${A}
> > > > >
> > > > > A=`expr $A + 1`
> > > > >
> > > > > done
> > > > >
> > > > > done
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > $ cat moduleList
> > > > >
> > > > >
> > > > >
> > > > > accessibility
> > > > >
> > > > > archive
> > > > >
> > > > > auth
> > > > >
> > > > > awt
> > > > >
> > > > > beans
> > > > >
> > > > > crypto
> > > > >
> > > > > instrument
> > > > >
> > > > > jndi
> > > > >
> > > > > lang-management
> > > > >
> > > > > logging
> > > > >
> > > > > luni
> > > > >
> > > > > math
> > > > >
> > > > > nio
> > > > >
> > > > > nio_char
> > > > >
> > > > > prefs
> > > > >
> > > > > print
> > > > >
> > > > > regex
> > > > >
> > > > > rmi
> > > > >
> > > > > security
> > > > >
> > > > > sound
> > > > >
> > > > > sql
> > > > >
> > > > > swing
> > > > >
> > > > > text
> > > > >
> > > > > tools
> > > > >
> > > > > x-net
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I've observed the following failures on svn=r476124
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > *Module*
> > > > >
> > > > > *Test*
> > > > >
> > > > > *Number of failures*
> > > > >
> > > > > *issue*
> > > > >
> > > > > luni
> > > > >
> > > > >
> > > > org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> > > > >
> > > > > 50 out of 50
> > > > >
> > > > > 1879 < http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> > > > >
> > > > > luni
> > > > >
> > > > > tests.api.java.net.InetAddressTest
> > > > >
> > > > > 50 out of 50
> > > > >
> > > > > Test was eliminated from repository after Novenber,17
> > > > >
> > > > > prefs
> > > > >
> > > > > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> > > > >
> > > > > 50 out of 50
> > > > >
> > > > > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751 >
> > > > >
> > > > > swing
> > > > >
> > > > > javax.swing.text.WrappedPlainView_SimpleTest
> > > > >
> > > > > 1 time out of 50
> > > > >
> > > > > 1)
> > > > >
> > > > > swing
> > > > >
> > > > > javax.swing.SpinnerDateModelTest
> > > > >
> > > > > 35 times out of 50
> > > > >
> > > > > 2)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 1). Eror
> > > > >
> > > > > Timeout occurred
> > > > >
> > > > > junit.framework.AssertionFailedError: Timeout occurred
> > > > >
> > > > >
> > > > >
> > > > > 2). Failure
> > > > >
> > > > > expected:<0> but was:<7>
> > > > >
> > > > > junit.framework.AssertionFailedError : expected:<0> but was:<7> at
> > > > > javax.swing.SpinnerDateModelTest.testSpinnerDateModel (
> > > > > SpinnerDateModelTest.java:59) at
> > > > > java.lang.reflect.VMReflection.invokeMethod(Native
> > > > > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> > > > > BasicSwingTestCase.java) at
> > > > javax.swing.BasicSwingTestCase.runBareImpl (
> > > > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> > > > > BasicSwingTestCase.java ) at java.lang.Thread.run(Unknown Source)
> > > > >
> > > > >
> > > > >
> > > > > 2070 < http://issues.apache.org/jira/browse/HARMONY-2070> was not
> > > > reproduced
> > > > > during this test run
> > > > >
> > > > >
> > > > >
> > > > > I can't reproduce 1) and 2) today on svn = r477507
> > > > >
> > > > >
> > > > >
> > > > > I've excluded failed tests and restarted multiple test run on Win XP
> > > > in
> > > > > order to make sure there is no other sporadic failures.
> > > > >
> > > > > Also I'm going to start the multiple classlib tests run on SUSE 9
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To extract the results I've used commands:
> > > > >
> > > > > cd classlib/trunk/buid
> > > > >
> > > > > # find errors
> > > > >
> > > > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" "
> > > > {} \; >
> > > > > ERRORS
> > > > >
> > > > > # find failures
> > > > >
> > > > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> > > > > failures=\"[1-9]*\"" {} \; > FAILURES
> > > > >
> > > > > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> > > > >
> > > > >
> > > > >
> > > > > Also I've compared the number of files in test_report directories:
> > > > >
> > > > > #!sh
> > > > >
> > > > > cat modulesList | while read moduleName; do
> > > > >
> > > > > echo $moduleName
> > > > >
> > > > > A=1
> > > > >
> > > > > while [ "$A" -lt "51" ]; do
> > > > >
> > > > > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml
> > > > | wc
> > > > > -l`
> > > > >
> > > > > echo build/test_report.${moduleName}_${A} $L >>
> > > > > test_report_length
> > > > >
> > > > > A=`expr $A + 1`
> > > > >
> > > > > done
> > > > > done
> > > > >
> > > > > Thanks,
> > > > > Tanya
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by tatyana doubtsova <ta...@gmail.com>.
There are intermittent failures in nio module after applying fix to
http://issues.apache.org/jira/browse/HARMONY-2285. I udated the issue.
Thanks,
Tanya
On 11/24/06, tatyana doubtsova <ta...@gmail.com> wrote:
>
> I also created issues regarding intermittent failures on SUSE9:
> http://issues.apache.org/jira/browse/HARMONY-2315
> http://issues.apache.org/jira/browse/HARMONY-2307
>
> Thanks,
> Tanya
>
> On 11/23/06, tatyana doubtsova <ta...@gmail.com> wrote:
> >
> > I created lists of intermittent unit tests failures on Win XP in perTest
> > mode:
> > http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> > http://issues.apache.org/jira/browse/HARMONY-2284 - security module
> >
> > Could anybody take a look at it?
> >
> > I did not observe intermittent failures in other modules on Win XP so
> > far.
> > I'm going to continue iterative classlib tests runs.
> >
> > Thanks,
> > Tanya
> >
> > On 11/22/06, Alexei Fedotov <alexei.fedotov@gmail.com > wrote:
> >
> > > Tatiana,
> > > That's great! Feel free to file JIRA issues about new problems.
> > >
> > > This is quite interesting that you haven't discovered
> > > org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > > failure using effectively the same revision as I. This makes me think
> > > that my problems can be local to my computer.
> > >
> > > --
> > > Thank you,
> > > Alexei
> > >
> > > On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> > > each
> > > > module in order to reveal sporadic failures.
> > > >
> > > >
> > > >
> > > > The script is
> > > >
> > > >
> > > >
> > > > #!sh
> > > >
> > > > cat modulesList | while read moduleName; do
> > > >
> > > > A=0
> > > >
> > > > while [ "$A" -lt "50" ]; do
> > > >
> > > > echo ITERATION $A
> > > >
> > > > ant -
> > > >
> > > Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> > > >
> > > > -Dbuild.module=$moduleName -
> > > > Dhy.test.forkmode=perTest \
> > > >
> > > > test 2>&1 | tee log_${moduleName}_${A}.txt
> > > >
> > > > cp -rf build/test_report
> > > build/test_report.${moduleName}_${A}
> > > >
> > > > A=`expr $A + 1`
> > > >
> > > > done
> > > >
> > > > done
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > $ cat moduleList
> > > >
> > > >
> > > >
> > > > accessibility
> > > >
> > > > archive
> > > >
> > > > auth
> > > >
> > > > awt
> > > >
> > > > beans
> > > >
> > > > crypto
> > > >
> > > > instrument
> > > >
> > > > jndi
> > > >
> > > > lang-management
> > > >
> > > > logging
> > > >
> > > > luni
> > > >
> > > > math
> > > >
> > > > nio
> > > >
> > > > nio_char
> > > >
> > > > prefs
> > > >
> > > > print
> > > >
> > > > regex
> > > >
> > > > rmi
> > > >
> > > > security
> > > >
> > > > sound
> > > >
> > > > sql
> > > >
> > > > swing
> > > >
> > > > text
> > > >
> > > > tools
> > > >
> > > > x-net
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I've observed the following failures on svn=r476124
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *Module*
> > > >
> > > > *Test*
> > > >
> > > > *Number of failures*
> > > >
> > > > *issue*
> > > >
> > > > luni
> > > >
> > > >
> > > org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> > > >
> > > > 50 out of 50
> > > >
> > > > 1879 < http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> > > >
> > > > luni
> > > >
> > > > tests.api.java.net.InetAddressTest
> > > >
> > > > 50 out of 50
> > > >
> > > > Test was eliminated from repository after Novenber,17
> > > >
> > > > prefs
> > > >
> > > > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> > > >
> > > > 50 out of 50
> > > >
> > > > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751 >
> > > >
> > > > swing
> > > >
> > > > javax.swing.text.WrappedPlainView_SimpleTest
> > > >
> > > > 1 time out of 50
> > > >
> > > > 1)
> > > >
> > > > swing
> > > >
> > > > javax.swing.SpinnerDateModelTest
> > > >
> > > > 35 times out of 50
> > > >
> > > > 2)
> > > >
> > > >
> > > >
> > > >
> > > > 1). Eror
> > > >
> > > > Timeout occurred
> > > >
> > > > junit.framework.AssertionFailedError: Timeout occurred
> > > >
> > > >
> > > >
> > > > 2). Failure
> > > >
> > > > expected:<0> but was:<7>
> > > >
> > > > junit.framework.AssertionFailedError : expected:<0> but was:<7> at
> > > > javax.swing.SpinnerDateModelTest.testSpinnerDateModel (
> > > > SpinnerDateModelTest.java:59) at
> > > > java.lang.reflect.VMReflection.invokeMethod(Native
> > > > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> > > > BasicSwingTestCase.java) at
> > > javax.swing.BasicSwingTestCase.runBareImpl (
> > > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> > > > BasicSwingTestCase.java ) at java.lang.Thread.run(Unknown Source)
> > > >
> > > >
> > > >
> > > > 2070 < http://issues.apache.org/jira/browse/HARMONY-2070> was not
> > > reproduced
> > > > during this test run
> > > >
> > > >
> > > >
> > > > I can't reproduce 1) and 2) today on svn = r477507
> > > >
> > > >
> > > >
> > > > I've excluded failed tests and restarted multiple test run on Win XP
> > > in
> > > > order to make sure there is no other sporadic failures.
> > > >
> > > > Also I'm going to start the multiple classlib tests run on SUSE 9
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To extract the results I've used commands:
> > > >
> > > > cd classlib/trunk/buid
> > > >
> > > > # find errors
> > > >
> > > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" "
> > > {} \; >
> > > > ERRORS
> > > >
> > > > # find failures
> > > >
> > > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> > > > failures=\"[1-9]*\"" {} \; > FAILURES
> > > >
> > > > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> > > >
> > > >
> > > >
> > > > Also I've compared the number of files in test_report directories:
> > > >
> > > > #!sh
> > > >
> > > > cat modulesList | while read moduleName; do
> > > >
> > > > echo $moduleName
> > > >
> > > > A=1
> > > >
> > > > while [ "$A" -lt "51" ]; do
> > > >
> > > > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml
> > > | wc
> > > > -l`
> > > >
> > > > echo build/test_report.${moduleName}_${A} $L >>
> > > > test_report_length
> > > >
> > > > A=`expr $A + 1`
> > > >
> > > > done
> > > > done
> > > >
> > > > Thanks,
> > > > Tanya
> > > >
> > > >
> > >
> >
> >
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by tatyana doubtsova <ta...@gmail.com>.
I also created issues regarding intermittent failures on SUSE9:
http://issues.apache.org/jira/browse/HARMONY-2315
http://issues.apache.org/jira/browse/HARMONY-2307
Thanks,
Tanya
On 11/23/06, tatyana doubtsova <ta...@gmail.com> wrote:
>
> I created lists of intermittent unit tests failures on Win XP in perTest
> mode:
> http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> http://issues.apache.org/jira/browse/HARMONY-2284 - security module
>
> Could anybody take a look at it?
>
> I did not observe intermittent failures in other modules on Win XP so far.
>
> I'm going to continue iterative classlib tests runs.
>
> Thanks,
> Tanya
>
> On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
>
> > Tatiana,
> > That's great! Feel free to file JIRA issues about new problems.
> >
> > This is quite interesting that you haven't discovered
> > org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > failure using effectively the same revision as I. This makes me think
> > that my problems can be local to my computer.
> >
> > --
> > Thank you,
> > Alexei
> >
> > On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > > Hello,
> > >
> > > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> > each
> > > module in order to reveal sporadic failures.
> > >
> > >
> > >
> > > The script is
> > >
> > >
> > >
> > > #!sh
> > >
> > > cat modulesList | while read moduleName; do
> > >
> > > A=0
> > >
> > > while [ "$A" -lt "50" ]; do
> > >
> > > echo ITERATION $A
> > >
> > > ant -
> > >
> > Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> > >
> > > -Dbuild.module=$moduleName -
> > > Dhy.test.forkmode=perTest \
> > >
> > > test 2>&1 | tee log_${moduleName}_${A}.txt
> > >
> > > cp -rf build/test_report
> > build/test_report.${moduleName}_${A}
> > >
> > > A=`expr $A + 1`
> > >
> > > done
> > >
> > > done
> > >
> > >
> > >
> > >
> > >
> > > $ cat moduleList
> > >
> > >
> > >
> > > accessibility
> > >
> > > archive
> > >
> > > auth
> > >
> > > awt
> > >
> > > beans
> > >
> > > crypto
> > >
> > > instrument
> > >
> > > jndi
> > >
> > > lang-management
> > >
> > > logging
> > >
> > > luni
> > >
> > > math
> > >
> > > nio
> > >
> > > nio_char
> > >
> > > prefs
> > >
> > > print
> > >
> > > regex
> > >
> > > rmi
> > >
> > > security
> > >
> > > sound
> > >
> > > sql
> > >
> > > swing
> > >
> > > text
> > >
> > > tools
> > >
> > > x-net
> > >
> > >
> > >
> > >
> > >
> > > I've observed the following failures on svn=r476124
> > >
> > >
> > >
> > >
> > >
> > > *Module*
> > >
> > > *Test*
> > >
> > > *Number of failures*
> > >
> > > *issue*
> > >
> > > luni
> > >
> > >
> > org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> > >
> > > 50 out of 50
> > >
> > > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> > >
> > > luni
> > >
> > > tests.api.java.net.InetAddressTest
> > >
> > > 50 out of 50
> > >
> > > Test was eliminated from repository after Novenber,17
> > >
> > > prefs
> > >
> > > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> > >
> > > 50 out of 50
> > >
> > > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
> > >
> > > swing
> > >
> > > javax.swing.text.WrappedPlainView_SimpleTest
> > >
> > > 1 time out of 50
> > >
> > > 1)
> > >
> > > swing
> > >
> > > javax.swing.SpinnerDateModelTest
> > >
> > > 35 times out of 50
> > >
> > > 2)
> > >
> > >
> > >
> > >
> > > 1). Eror
> > >
> > > Timeout occurred
> > >
> > > junit.framework.AssertionFailedError: Timeout occurred
> > >
> > >
> > >
> > > 2). Failure
> > >
> > > expected:<0> but was:<7>
> > >
> > > junit.framework.AssertionFailedError : expected:<0> but was:<7> at
> > > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
> > > SpinnerDateModelTest.java:59) at
> > > java.lang.reflect.VMReflection.invokeMethod(Native
> > > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl
> > (
> > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> > > BasicSwingTestCase.java ) at java.lang.Thread.run(Unknown Source)
> > >
> > >
> > >
> > > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
> > reproduced
> > > during this test run
> > >
> > >
> > >
> > > I can't reproduce 1) and 2) today on svn = r477507
> > >
> > >
> > >
> > > I've excluded failed tests and restarted multiple test run on Win XP
> > in
> > > order to make sure there is no other sporadic failures.
> > >
> > > Also I'm going to start the multiple classlib tests run on SUSE 9
> > >
> > >
> > >
> > >
> > >
> > > To extract the results I've used commands:
> > >
> > > cd classlib/trunk/buid
> > >
> > > # find errors
> > >
> > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" "
> > {} \; >
> > > ERRORS
> > >
> > > # find failures
> > >
> > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> > > failures=\"[1-9]*\"" {} \; > FAILURES
> > >
> > > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> > >
> > >
> > >
> > > Also I've compared the number of files in test_report directories:
> > >
> > > #!sh
> > >
> > > cat modulesList | while read moduleName; do
> > >
> > > echo $moduleName
> > >
> > > A=1
> > >
> > > while [ "$A" -lt "51" ]; do
> > >
> > > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml |
> > wc
> > > -l`
> > >
> > > echo build/test_report.${moduleName}_${A} $L >>
> > > test_report_length
> > >
> > > A=`expr $A + 1`
> > >
> > > done
> > > done
> > >
> > > Thanks,
> > > Tanya
> > >
> > >
> >
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by tatyana doubtsova <ta...@gmail.com>.
To incorporate iterative runs of classlib tests as possible target of CC,
the script invocation via exec can be used. What do you think?
On 11/27/06, Alexei Fedotov <al...@gmail.com> wrote:
>
> Geir,
>
> I support your point - a developer who resolves an intermittent issue
> needs a painless way to check his resolution.
>
> I see two ways to implement it:
> * Automatically generate a build script: Egor posted me a feedback
> that it is not quite readable approach.
> * Use <for> ant-contrib task: this adds ant-contrib dependency to the
> class library build system.
> * Make a clone from <junit> task: this adds a dependency from ANT source
> base.
>
> All,
> Before starting a patch discussion let me ask which of three do you
> think is a better approach?
>
> --
> Thank you,
> Alexei
>
> BTW, this ugly hack produced new reliability results which are
> available at
> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM#reliability.
>
>
> On 11/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> > Alexei Fedotov wrote:
> > > Tatiana,
> > > I cannot stop myself from thinking about your wonderful scripts.
> >
> > >
> > > 1.
> > > Looking at http://issues.apache.org/jira/browse/HARMONY-2282 I
> > > realized that in case of absence of DRLVM crash it would be quite
> > > useful to know if the bug is reproducible with J9.
> > >
> > > Failures on two different VMs convinces test authors to look in their
> > > tests once again to decide how valid they are. So if it wasn't
> > > difficult to launch your script for J9, this would be quite useful.
> >
> > +1
> >
> > >
> > > 2. The second thing which comes into my mind is speeding up test runs
> > > by hacking build.xml files:
> > >
> > > perl -i -e 'undef $/; $_ = <>; s/(<batchtest.*?<\/batchtest>)/$1 x
> > > 50/es; print' modules/*/build.xml
> > >
> > > You can revert build files later using svn revert modules/*/build.xml.
> > > I wonder if we can set forkmode to vary a reliability load from
> > > running all tests in the same JVM to running each test separately.
> >
> > Ugh. :) How about finding a way to incorporate this formally into the
> > build scripts, so it can simply be parameterized?
> >
> > geir
> >
> >
> >
>
Re: [general] New dependency for ant/lib (was Re: [drlvm][classlib unit tests] iterative runs)
Posted by Alexei Fedotov <al...@gmail.com>.
Geir,
Let me continue here.
As far as I understand the main purpose of build.bat script is to set
Microsoft compiler environment for Windows using a standard
environment setter vsvars32.bat. build.sh appeared for symmetry.
Class path modification can be coded in ant via exec()/<exec>
approach. Ant already forks in DRLVM build to download ant-contrib
package first, and then dynamically link to it.
If we choose forking approach for a class library copying a compiler
to $ANT_HOME/lib and being squeamish will no longer be required.
As for your question about <junit> clone, I was not precise in my
statement. I believe we can extend
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask by our task,
and for this apprach ant binary is more than enough.
--
Thank you,
Alexei
On 11/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> This thread and some other thoughts I have banging around in head (like
> how to get rid of "build.sh" in DRLVM) is really a subject for everyone,
> not DRLVM.
>
> A) The iterated unit test approach has shown lots of benefit, and we'd
> like to add it as at least some kind of option to the build system, so
> that CI systems can invoke a classlib unit test run (and DRLVM unit test
> run) iteratively in the same VM. The simplest solution is the
> ant-contrib "for" loop, but IIRC, this needs to be either on the
> classpath or in ant/lib.
>
> B) The DRLVM build system requires a bat/sh to launch ant, to achieve
> the same purpose - to preload a bunch of stuff onto the classpath.
>
>
> First question - is there a way to dynamically add via cmdline or -ish
> things to the classpath for ant? (Paging Matt Benson...)
>
> Second - if not, can we do the equiv of an exec() with ant ? create a
> 'top level' build.xml that when invoked, fixes up the classpath and
> re-invokes ant using the new classpath, passing through all command line
> params and targets?
>
> Finally - if we can't do anything like this, does anyone mind if we
> create additional detritus in ant/lib like we do with ecj.jar? We can
> make it automatic, I suppose, but I'm always squeamish about dropping
> stuff into ant/lib
>
> geir
>
>
>
> Geir Magnusson Jr. wrote:
> > Sorry - I missed this yesterday for some reason
> >
> > Alexei Fedotov wrote:
> >> Geir,
> >>
> >> I support your point - a developer who resolves an intermittent issue
> >> needs a painless way to check his resolution.
> >
> > That, and we need to see if we are creating new intermittent issues.
> >
> >>
> >> I see two ways to implement it:
> >> * Automatically generate a build script: Egor posted me a feedback
> >> that it is not quite readable approach.
> >
> > I thought of this, and figure it's our last resort.
> >
> >> * Use <for> ant-contrib task: this adds ant-contrib dependency to the
> >> class library build system.
> >
> > Sure - but can we make that optional? No... I guess not.
> >
> >> * Make a clone from <junit> task: this adds a dependency from ANT
> >> source base.
> >
> > Source? Doesn't it just add a dep on the ant binary for building our tool?
> >
> >>
> >> All,
> >> Before starting a patch discussion let me ask which of three do you
> >> think is a better approach?
> >>
> >
> > This is buried here... this needs a new thread...
> >
> > geir
>
Re: [general] New dependency for ant/lib (was Re: [drlvm][classlib
unit tests] iterative runs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Matt Benson wrote:
> --- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> [SNIP]
>> First question - is there a way to dynamically add
>> via cmdline or -ish
>> things to the classpath for ant? (Paging Matt
>> Benson...)
>>
>
> Here I am... :) via command line is easy:
>
> -lib dir-or-jar
>
That doesn't solve it, because we want people to just do "ant".
> There is also
> http://enitsys.sourceforge.net/ant-classloadertask/
> which might be of use but still results in the same
> ultimate problem of adding THAT library instead of
> another. On ant-dev we have a dead discussion of a
> similar task that could be shipped with Ant; I'm about
> to resurrect that thread one last time and we'll see
> what can be done for 1.7, if anything.
That would be convenient
>
>> Second - if not, can we do the equiv of an exec()
>> with ant ? create a
>> 'top level' build.xml that when invoked, fixes up
>> the classpath and
>> re-invokes ant using the new classpath, passing
>> through all command line
>> params and targets?
>
> You said "if not," but I'll address this anyway: You
> can <java
> classname="org.apache.tools.ant.launch.Launcher"> or
> <java classname="org.apache.tools.ant.Main">, but you
> are on your own to keep up with the appropriate
> command-line parameters. :( Not ideal IMO.
Right - that's a maintenance problem. Thanks
geir
>
> HTH,
> Matt
> [SNIP]
>
>
>
> ____________________________________________________________________________________
> Want to start your own business?
> Learn how on Yahoo! Small Business.
> http://smallbusiness.yahoo.com/r-index
Re: [general] New dependency for ant/lib (was Re: [drlvm][classlib unit tests] iterative runs)
Posted by Matt Benson <gu...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
[SNIP]
> First question - is there a way to dynamically add
> via cmdline or -ish
> things to the classpath for ant? (Paging Matt
> Benson...)
>
Here I am... :) via command line is easy:
-lib dir-or-jar
There is also
http://enitsys.sourceforge.net/ant-classloadertask/
which might be of use but still results in the same
ultimate problem of adding THAT library instead of
another. On ant-dev we have a dead discussion of a
similar task that could be shipped with Ant; I'm about
to resurrect that thread one last time and we'll see
what can be done for 1.7, if anything.
> Second - if not, can we do the equiv of an exec()
> with ant ? create a
> 'top level' build.xml that when invoked, fixes up
> the classpath and
> re-invokes ant using the new classpath, passing
> through all command line
> params and targets?
You said "if not," but I'll address this anyway: You
can <java
classname="org.apache.tools.ant.launch.Launcher"> or
<java classname="org.apache.tools.ant.Main">, but you
are on your own to keep up with the appropriate
command-line parameters. :( Not ideal IMO.
HTH,
Matt
[SNIP]
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index
[general] New dependency for ant/lib (was Re: [drlvm][classlib unit
tests] iterative runs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
This thread and some other thoughts I have banging around in head (like
how to get rid of "build.sh" in DRLVM) is really a subject for everyone,
not DRLVM.
A) The iterated unit test approach has shown lots of benefit, and we'd
like to add it as at least some kind of option to the build system, so
that CI systems can invoke a classlib unit test run (and DRLVM unit test
run) iteratively in the same VM. The simplest solution is the
ant-contrib "for" loop, but IIRC, this needs to be either on the
classpath or in ant/lib.
B) The DRLVM build system requires a bat/sh to launch ant, to achieve
the same purpose - to preload a bunch of stuff onto the classpath.
First question - is there a way to dynamically add via cmdline or -ish
things to the classpath for ant? (Paging Matt Benson...)
Second - if not, can we do the equiv of an exec() with ant ? create a
'top level' build.xml that when invoked, fixes up the classpath and
re-invokes ant using the new classpath, passing through all command line
params and targets?
Finally - if we can't do anything like this, does anyone mind if we
create additional detritus in ant/lib like we do with ecj.jar? We can
make it automatic, I suppose, but I'm always squeamish about dropping
stuff into ant/lib
geir
Geir Magnusson Jr. wrote:
> Sorry - I missed this yesterday for some reason
>
> Alexei Fedotov wrote:
>> Geir,
>>
>> I support your point - a developer who resolves an intermittent issue
>> needs a painless way to check his resolution.
>
> That, and we need to see if we are creating new intermittent issues.
>
>>
>> I see two ways to implement it:
>> * Automatically generate a build script: Egor posted me a feedback
>> that it is not quite readable approach.
>
> I thought of this, and figure it's our last resort.
>
>> * Use <for> ant-contrib task: this adds ant-contrib dependency to the
>> class library build system.
>
> Sure - but can we make that optional? No... I guess not.
>
>> * Make a clone from <junit> task: this adds a dependency from ANT
>> source base.
>
> Source? Doesn't it just add a dep on the ant binary for building our tool?
>
>>
>> All,
>> Before starting a patch discussion let me ask which of three do you
>> think is a better approach?
>>
>
> This is buried here... this needs a new thread...
>
> geir
Re: [drlvm][classlib unit tests] iterative runs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Sorry - I missed this yesterday for some reason
Alexei Fedotov wrote:
> Geir,
>
> I support your point - a developer who resolves an intermittent issue
> needs a painless way to check his resolution.
That, and we need to see if we are creating new intermittent issues.
>
> I see two ways to implement it:
> * Automatically generate a build script: Egor posted me a feedback
> that it is not quite readable approach.
I thought of this, and figure it's our last resort.
> * Use <for> ant-contrib task: this adds ant-contrib dependency to the
> class library build system.
Sure - but can we make that optional? No... I guess not.
> * Make a clone from <junit> task: this adds a dependency from ANT source
> base.
Source? Doesn't it just add a dep on the ant binary for building our tool?
>
> All,
> Before starting a patch discussion let me ask which of three do you
> think is a better approach?
>
This is buried here... this needs a new thread...
geir
Re: [drlvm][classlib unit tests] iterative runs
Posted by Alexei Fedotov <al...@gmail.com>.
Geir,
I support your point - a developer who resolves an intermittent issue
needs a painless way to check his resolution.
I see two ways to implement it:
* Automatically generate a build script: Egor posted me a feedback
that it is not quite readable approach.
* Use <for> ant-contrib task: this adds ant-contrib dependency to the
class library build system.
* Make a clone from <junit> task: this adds a dependency from ANT source base.
All,
Before starting a patch discussion let me ask which of three do you
think is a better approach?
--
Thank you,
Alexei
BTW, this ugly hack produced new reliability results which are
available at http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM#reliability.
On 11/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Alexei Fedotov wrote:
> > Tatiana,
> > I cannot stop myself from thinking about your wonderful scripts.
>
> >
> > 1.
> > Looking at http://issues.apache.org/jira/browse/HARMONY-2282 I
> > realized that in case of absence of DRLVM crash it would be quite
> > useful to know if the bug is reproducible with J9.
> >
> > Failures on two different VMs convinces test authors to look in their
> > tests once again to decide how valid they are. So if it wasn't
> > difficult to launch your script for J9, this would be quite useful.
>
> +1
>
> >
> > 2. The second thing which comes into my mind is speeding up test runs
> > by hacking build.xml files:
> >
> > perl -i -e 'undef $/; $_ = <>; s/(<batchtest.*?<\/batchtest>)/$1 x
> > 50/es; print' modules/*/build.xml
> >
> > You can revert build files later using svn revert modules/*/build.xml.
> > I wonder if we can set forkmode to vary a reliability load from
> > running all tests in the same JVM to running each test separately.
>
> Ugh. :) How about finding a way to incorporate this formally into the
> build scripts, so it can simply be parameterized?
>
> geir
>
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Fedotov wrote:
> Tatiana,
> I cannot stop myself from thinking about your wonderful scripts.
>
> 1.
> Looking at http://issues.apache.org/jira/browse/HARMONY-2282 I
> realized that in case of absence of DRLVM crash it would be quite
> useful to know if the bug is reproducible with J9.
>
> Failures on two different VMs convinces test authors to look in their
> tests once again to decide how valid they are. So if it wasn't
> difficult to launch your script for J9, this would be quite useful.
+1
>
> 2. The second thing which comes into my mind is speeding up test runs
> by hacking build.xml files:
>
> perl -i -e 'undef $/; $_ = <>; s/(<batchtest.*?<\/batchtest>)/$1 x
> 50/es; print' modules/*/build.xml
>
> You can revert build files later using svn revert modules/*/build.xml.
> I wonder if we can set forkmode to vary a reliability load from
> running all tests in the same JVM to running each test separately.
Ugh. :) How about finding a way to incorporate this formally into the
build scripts, so it can simply be parameterized?
geir
Re: [drlvm][classlib unit tests] iterative runs
Posted by Alexei Fedotov <al...@gmail.com>.
Tatiana,
I cannot stop myself from thinking about your wonderful scripts.
1.
Looking at http://issues.apache.org/jira/browse/HARMONY-2282 I
realized that in case of absence of DRLVM crash it would be quite
useful to know if the bug is reproducible with J9.
Failures on two different VMs convinces test authors to look in their
tests once again to decide how valid they are. So if it wasn't
difficult to launch your script for J9, this would be quite useful.
2. The second thing which comes into my mind is speeding up test runs
by hacking build.xml files:
perl -i -e 'undef $/; $_ = <>; s/(<batchtest.*?<\/batchtest>)/$1 x
50/es; print' modules/*/build.xml
You can revert build files later using svn revert modules/*/build.xml.
I wonder if we can set forkmode to vary a reliability load from
running all tests in the same JVM to running each test separately.
--
Thank you,
Alexei
On 11/23/06, tatyana doubtsova <ta...@gmail.com> wrote:
> I created lists of intermittent unit tests failures on Win XP in perTest
> mode:
> http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
> http://issues.apache.org/jira/browse/HARMONY-2284 - security module
>
> Could anybody take a look at it?
>
> I did not observe intermittent failures in other modules on Win XP so far.
> I'm going to continue iterative classlib tests runs.
>
> Thanks,
> Tanya
>
> On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
>
> > Tatiana,
> > That's great! Feel free to file JIRA issues about new problems.
> >
> > This is quite interesting that you haven't discovered
> > org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > failure using effectively the same revision as I. This makes me think
> > that my problems can be local to my computer.
> >
> > --
> > Thank you,
> > Alexei
> >
> > On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > > Hello,
> > >
> > > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> > each
> > > module in order to reveal sporadic failures.
> > >
> > >
> > >
> > > The script is
> > >
> > >
> > >
> > > #!sh
> > >
> > > cat modulesList | while read moduleName; do
> > >
> > > A=0
> > >
> > > while [ "$A" -lt "50" ]; do
> > >
> > > echo ITERATION $A
> > >
> > > ant -
> > >
> > Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> > >
> > > -Dbuild.module=$moduleName -
> > > Dhy.test.forkmode=perTest \
> > >
> > > test 2>&1 | tee log_${moduleName}_${A}.txt
> > >
> > > cp -rf build/test_report build/test_report.${moduleName}_${A}
> > >
> > > A=`expr $A + 1`
> > >
> > > done
> > >
> > > done
> > >
> > >
> > >
> > >
> > >
> > > $ cat moduleList
> > >
> > >
> > >
> > > accessibility
> > >
> > > archive
> > >
> > > auth
> > >
> > > awt
> > >
> > > beans
> > >
> > > crypto
> > >
> > > instrument
> > >
> > > jndi
> > >
> > > lang-management
> > >
> > > logging
> > >
> > > luni
> > >
> > > math
> > >
> > > nio
> > >
> > > nio_char
> > >
> > > prefs
> > >
> > > print
> > >
> > > regex
> > >
> > > rmi
> > >
> > > security
> > >
> > > sound
> > >
> > > sql
> > >
> > > swing
> > >
> > > text
> > >
> > > tools
> > >
> > > x-net
> > >
> > >
> > >
> > >
> > >
> > > I've observed the following failures on svn=r476124
> > >
> > >
> > >
> > >
> > >
> > > *Module*
> > >
> > > *Test*
> > >
> > > *Number of failures*
> > >
> > > *issue*
> > >
> > > luni
> > >
> > >
> > org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> > >
> > > 50 out of 50
> > >
> > > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> > >
> > > luni
> > >
> > > tests.api.java.net.InetAddressTest
> > >
> > > 50 out of 50
> > >
> > > Test was eliminated from repository after Novenber,17
> > >
> > > prefs
> > >
> > > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> > >
> > > 50 out of 50
> > >
> > > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
> > >
> > > swing
> > >
> > > javax.swing.text.WrappedPlainView_SimpleTest
> > >
> > > 1 time out of 50
> > >
> > > 1)
> > >
> > > swing
> > >
> > > javax.swing.SpinnerDateModelTest
> > >
> > > 35 times out of 50
> > >
> > > 2)
> > >
> > >
> > >
> > >
> > > 1). Eror
> > >
> > > Timeout occurred
> > >
> > > junit.framework.AssertionFailedError: Timeout occurred
> > >
> > >
> > >
> > > 2). Failure
> > >
> > > expected:<0> but was:<7>
> > >
> > > junit.framework.AssertionFailedError: expected:<0> but was:<7> at
> > > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
> > > SpinnerDateModelTest.java:59) at
> > > java.lang.reflect.VMReflection.invokeMethod(Native
> > > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl(
> > > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> > > BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
> > >
> > >
> > >
> > > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
> > reproduced
> > > during this test run
> > >
> > >
> > >
> > > I can't reproduce 1) and 2) today on svn = r477507
> > >
> > >
> > >
> > > I've excluded failed tests and restarted multiple test run on Win XP in
> > > order to make sure there is no other sporadic failures.
> > >
> > > Also I'm going to start the multiple classlib tests run on SUSE 9
> > >
> > >
> > >
> > >
> > >
> > > To extract the results I've used commands:
> > >
> > > cd classlib/trunk/buid
> > >
> > > # find errors
> > >
> > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" " {}
> > \; >
> > > ERRORS
> > >
> > > # find failures
> > >
> > > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> > > failures=\"[1-9]*\"" {} \; > FAILURES
> > >
> > > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> > >
> > >
> > >
> > > Also I've compared the number of files in test_report directories:
> > >
> > > #!sh
> > >
> > > cat modulesList | while read moduleName; do
> > >
> > > echo $moduleName
> > >
> > > A=1
> > >
> > > while [ "$A" -lt "51" ]; do
> > >
> > > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml | wc
> > > -l`
> > >
> > > echo build/test_report.${moduleName}_${A} $L >>
> > > test_report_length
> > >
> > > A=`expr $A + 1`
> > >
> > > done
> > > done
> > >
> > > Thanks,
> > > Tanya
> > >
> > >
> >
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by tatyana doubtsova <ta...@gmail.com>.
I created lists of intermittent unit tests failures on Win XP in perTest
mode:
http://issues.apache.org/jira/browse/HARMONY-2282 - swing module
http://issues.apache.org/jira/browse/HARMONY-2284 - security module
Could anybody take a look at it?
I did not observe intermittent failures in other modules on Win XP so far.
I'm going to continue iterative classlib tests runs.
Thanks,
Tanya
On 11/22/06, Alexei Fedotov <al...@gmail.com> wrote:
> Tatiana,
> That's great! Feel free to file JIRA issues about new problems.
>
> This is quite interesting that you haven't discovered
> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> failure using effectively the same revision as I. This makes me think
> that my problems can be local to my computer.
>
> --
> Thank you,
> Alexei
>
> On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> > Hello,
> >
> > I've run classlib unit tests on Win XP in Other VM mode 50 times for
> each
> > module in order to reveal sporadic failures.
> >
> >
> >
> > The script is
> >
> >
> >
> > #!sh
> >
> > cat modulesList | while read moduleName; do
> >
> > A=0
> >
> > while [ "$A" -lt "50" ]; do
> >
> > echo ITERATION $A
> >
> > ant -
> >
> Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
> >
> > -Dbuild.module=$moduleName -
> > Dhy.test.forkmode=perTest \
> >
> > test 2>&1 | tee log_${moduleName}_${A}.txt
> >
> > cp -rf build/test_report build/test_report.${moduleName}_${A}
> >
> > A=`expr $A + 1`
> >
> > done
> >
> > done
> >
> >
> >
> >
> >
> > $ cat moduleList
> >
> >
> >
> > accessibility
> >
> > archive
> >
> > auth
> >
> > awt
> >
> > beans
> >
> > crypto
> >
> > instrument
> >
> > jndi
> >
> > lang-management
> >
> > logging
> >
> > luni
> >
> > math
> >
> > nio
> >
> > nio_char
> >
> > prefs
> >
> > print
> >
> > regex
> >
> > rmi
> >
> > security
> >
> > sound
> >
> > sql
> >
> > swing
> >
> > text
> >
> > tools
> >
> > x-net
> >
> >
> >
> >
> >
> > I've observed the following failures on svn=r476124
> >
> >
> >
> >
> >
> > *Module*
> >
> > *Test*
> >
> > *Number of failures*
> >
> > *issue*
> >
> > luni
> >
> >
> org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
> >
> > 50 out of 50
> >
> > 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
> >
> > luni
> >
> > tests.api.java.net.InetAddressTest
> >
> > 50 out of 50
> >
> > Test was eliminated from repository after Novenber,17
> >
> > prefs
> >
> > org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
> >
> > 50 out of 50
> >
> > 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
> >
> > swing
> >
> > javax.swing.text.WrappedPlainView_SimpleTest
> >
> > 1 time out of 50
> >
> > 1)
> >
> > swing
> >
> > javax.swing.SpinnerDateModelTest
> >
> > 35 times out of 50
> >
> > 2)
> >
> >
> >
> >
> > 1). Eror
> >
> > Timeout occurred
> >
> > junit.framework.AssertionFailedError: Timeout occurred
> >
> >
> >
> > 2). Failure
> >
> > expected:<0> but was:<7>
> >
> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at
> > javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
> > SpinnerDateModelTest.java:59) at
> > java.lang.reflect.VMReflection.invokeMethod(Native
> > Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl(
> > BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> > BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
> >
> >
> >
> > 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not
> reproduced
> > during this test run
> >
> >
> >
> > I can't reproduce 1) and 2) today on svn = r477507
> >
> >
> >
> > I've excluded failed tests and restarted multiple test run on Win XP in
> > order to make sure there is no other sporadic failures.
> >
> > Also I'm going to start the multiple classlib tests run on SUSE 9
> >
> >
> >
> >
> >
> > To extract the results I've used commands:
> >
> > cd classlib/trunk/buid
> >
> > # find errors
> >
> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" " {}
> \; >
> > ERRORS
> >
> > # find failures
> >
> > find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> > failures=\"[1-9]*\"" {} \; > FAILURES
> >
> > find . -type f -size 0 | grep *.xml > ZERO_LENGTH
> >
> >
> >
> > Also I've compared the number of files in test_report directories:
> >
> > #!sh
> >
> > cat modulesList | while read moduleName; do
> >
> > echo $moduleName
> >
> > A=1
> >
> > while [ "$A" -lt "51" ]; do
> >
> > L=`ls -1 build/test_report.${moduleName}_${A} | grep xml | wc
> > -l`
> >
> > echo build/test_report.${moduleName}_${A} $L >>
> > test_report_length
> >
> > A=`expr $A + 1`
> >
> > done
> > done
> >
> > Thanks,
> > Tanya
> >
> >
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Alexei Fedotov <al...@gmail.com>.
Gregory, Ivan,
Thank you for a deep and thorough research on Windows architecture,
and a wonderful result. Keep doing great things!
--
With best regards,
Alexei
On 11/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
> On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
> > Tatiana,
> > That's great! Feel free to file JIRA issues about new problems.
> >
> > This is quite interesting that you haven't discovered
> > org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > failure using effectively the same revision as I. This makes me think
> > that my problems can be local to my computer.
>
> The problem with this test appeared to be a regression after HARMONY-2006.
> DRLVM started to halt of all unknown exceptions passing to VEH handler
> when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH
> handler is called in case of C++ exceptions too.
>
> Also it appeared that windows kernel uses exceptions inside of itself, so VEH
> handler is called for some API functions which return an error, like in case
> of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any
> unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler.
> Now it started to call DebugBreak in case when
> UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
>
> Ivan offered a quick fix in HARMONY-2285, which calls this function only if
> IS_ERROR [2] macro returns true for the exception code. The fix helped, and
> now in interactive test runs when -Dvm.assert_dialog=true (default) tests
> pass just as well as in non-interactive mode.
>
> I am still a bit unsure, why mess around with unknown exception codes, maybe
> it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging
> dialog will be open by the default NT handler.
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
>
> [2]
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
>
> --
> Gregory
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> On 11/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > Correction below
> >
> > Gregory Shimansky wrote:
> > > On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
> > >> Tatiana,
> > >> That's great! Feel free to file JIRA issues about new problems.
> > >>
> > >> This is quite interesting that you haven't discovered
> > >> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> > >> failure using effectively the same revision as I. This makes me think
> > >> that my problems can be local to my computer.
> > >
> > > The problem with this test appeared to be a regression after HARMONY-2006.
> > > DRLVM started to halt of all unknown exceptions passing to VEH handler
> > > when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH
> > > handler is called in case of C++ exceptions too.
> > >
> > > Also it appeared that windows kernel uses exceptions inside of itself, so VEH
> > > handler is called for some API functions which return an error, like in case
> > > of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any
> > > unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler.
> >
> > It should have been "EXCEPTION_CONTINUE_SEARCH" in this text, I pasted a
> > wrong one from the code. This code was used to find a suitable handler
> > (or show the error window) for the received exception.
> >
> > > Now it started to call DebugBreak in case when
> > > UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
> > >
> > > Ivan offered a quick fix in HARMONY-2285, which calls this function only if
> > > IS_ERROR [2] macro returns true for the exception code. The fix helped, and
> > > now in interactive test runs when -Dvm.assert_dialog=true (default) tests
> > > pass just as well as in non-interactive mode.
> > >
> > > I am still a bit unsure, why mess around with unknown exception codes, maybe
> > > it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging
> > > dialog will be open by the default NT handler.
>
> Agree! It seems like a mess for me as well. The most clean approach is
> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> native code.
Ok, I was not 100% accurate here. We still need to handle
STATUS_STACK_OVERFLOW & JVMTI_EXCEPTION_STATUS.
I would suggest to fix the problem in this way instead of
> HARMONY-2285. Currently, the launcher installs its own exception
> handler which blocks default exception handler. So if we wish to have
> a debug dialog we need to disable launcher's handler somehow. Should
> we discuss it in a new thread?
>
>
> Thanks
> Evgueni
>
> > >
> > > [1]
> > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
> > >
> > > [2]
> > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
Re: [drlvm] Redesign of hardware exceptions/signals handling
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/27/06, Salikh Zakirov <Sa...@intel.com> wrote:
> Evgueni Brevnov wrote:
> > Hi guys,
> >
> > Do I get it correctly that HARMONY-2320 contains all suggested
> > changes? I'm asking this because it differs from what was posted to
> > another thread "[drlvm][classlib unit tests] iterative runs".
>
> Yes, this is correct.
> HARMONY-2320 contains a later patch version, which changes to using Registers
> instead of M2nFrame pushing assembly, as Gregory suggested.
Aha, that is exactly I was going to suggest :-)
>
> Currently, I'm chasing the enumeration problem that results from this change.
>
> The next step will be to refactor jvmti stepping code to use snapshot Registers
> instead of assembly too.
>
>
That's good. Though I haven't looked through the patch thoroughly I
like the way it goes. It will be interesting to look at the final
version.
Thanks
Evgueni
Re: [drlvm] Redesign of hardware exceptions/signals handling
Posted by Salikh Zakirov <Sa...@Intel.com>.
Evgueni Brevnov wrote:
> Hi guys,
>
> Do I get it correctly that HARMONY-2320 contains all suggested
> changes? I'm asking this because it differs from what was posted to
> another thread "[drlvm][classlib unit tests] iterative runs".
Yes, this is correct.
HARMONY-2320 contains a later patch version, which changes to using Registers
instead of M2nFrame pushing assembly, as Gregory suggested.
Currently, I'm chasing the enumeration problem that results from this change.
The next step will be to refactor jvmti stepping code to use snapshot Registers
instead of assembly too.
Re: [drlvm] Redesign of hardware exceptions/signals handling
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi guys,
Do I get it correctly that HARMONY-2320 contains all suggested
changes? I'm asking this because it differs from what was posted to
another thread "[drlvm][classlib unit tests] iterative runs".
Thanks
Evgueni
On 11/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> On Friday 24 November 2006 18:44 Salikh Zakirov wrote:
> > However, these patches somewhat regress in functionality:
> > I still haven't figured out how to piggy-back on exception throw
> > to call JVMTI callback and to restore stack guard page.
> > (the commented out block at the end of nt_exception_filter.cpp was doing it
> > before fix).
> >
> > Any ideas appreciated.
>
> I decided this deserves a separate topic. I think signals on unix deserve
> redesign along with NT exceptions since platform dependent part is actually
> quite small, and benefit is quite bit if we do this.
>
> I've reviewed the patch in HARMONY-2320, the changes are going in the right
> direction except for 2 things.
>
> 1. The function vm_identify_eip seems to be called twice now, first in
> vectored_exception_handler_internal, second time in c_exception_handler. The
> function is quite a heavy lookup and it would be better to have it called
> only once. Probably it will require passing one more argument to
> c_exception_handler. Maybe it is better to create a separate place for all
> this stuff in TLS, I mean exception class pointer, registers and in_java
> flag. This would save you from ESP manipulation and make the code more
> portable (any ideas how do these ESP manipulations on IPF? ;) ).
>
> 2. JVMTI functionality is going to be broken with this patch. The
> exception_catch handling callback should be changed to accept registers in
> TLS instead of an assembly stub (makes it more portable too). I think JVMTI
> breakpoints handler could be integrated with the new functionality and called
> from inside of c_exception_handler.
>
> I am very glad you've started to change this stuff (especially that you
> comment your code at every significant step). I would really like to help you
> because I've gone through doing a partial fix only for JVMTI, but now that it
> seems like all the rest has to be changed too I can share my experience.
>
> Isn't it better to use conventional DIE instead of assert(!"...")?
>
> --
> Gregory
>
[drlvm] Redesign of hardware exceptions/signals handling
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 24 November 2006 18:44 Salikh Zakirov wrote:
> However, these patches somewhat regress in functionality:
> I still haven't figured out how to piggy-back on exception throw
> to call JVMTI callback and to restore stack guard page.
> (the commented out block at the end of nt_exception_filter.cpp was doing it
> before fix).
>
> Any ideas appreciated.
I decided this deserves a separate topic. I think signals on unix deserve
redesign along with NT exceptions since platform dependent part is actually
quite small, and benefit is quite bit if we do this.
I've reviewed the patch in HARMONY-2320, the changes are going in the right
direction except for 2 things.
1. The function vm_identify_eip seems to be called twice now, first in
vectored_exception_handler_internal, second time in c_exception_handler. The
function is quite a heavy lookup and it would be better to have it called
only once. Probably it will require passing one more argument to
c_exception_handler. Maybe it is better to create a separate place for all
this stuff in TLS, I mean exception class pointer, registers and in_java
flag. This would save you from ESP manipulation and make the code more
portable (any ideas how do these ESP manipulations on IPF? ;) ).
2. JVMTI functionality is going to be broken with this patch. The
exception_catch handling callback should be changed to accept registers in
TLS instead of an assembly stub (makes it more portable too). I think JVMTI
breakpoints handler could be integrated with the new functionality and called
from inside of c_exception_handler.
I am very glad you've started to change this stuff (especially that you
comment your code at every significant step). I would really like to help you
because I've gone through doing a partial fix only for JVMTI, but now that it
seems like all the rest has to be changed too I can share my experience.
Isn't it better to use conventional DIE instead of assert(!"...")?
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/24/06, Salikh Zakirov <Sa...@intel.com> wrote:
> Evgueni Brevnov wrote:
> > Agree! It seems like a mess for me as well. The most clean approach is
> > to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> > native code.
>
> I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
> XP, and it turned out to be related to the hardware exception handling.
>
> Since the fix will involve significant modifications to the file
> vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
> I can do this modification too.
Sounds reasonable :-)
>
>
>
>
>
> P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
> Assume thread A handles NPE:
>
> A1) segfault occured
> A2) grab "system hwe lock" and call vectored_exception_handler
> A3) instantiate NullPointerException object
> A4) set up throwing NullPointerExceptionObject in the register snapshot
> A5) return from vectored_exception_handler release "system hwe lock"
>
> Let's next assume that garbage collection was started exactly when thread A
> was in progress of running NullPointerException constructor. Then, thread A
> will be suspended while still holding "system hwe lock".
>
> Another thread B at that moment may be blocked on a "system hwe lock",
> and since this lock is system and not known to Thread Manager, it just
> waits forever for thread B to reach a safepoint.
Hmmm .... this is intresting.... Good catch!
Evgueni
>
>
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/28/06, Gregory Shimansky <gs...@gmail.com> wrote:
> Weldon Washburn wrote:
> > On 11/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >>
> >> On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
> >> > > > A1) segfault occured
> >> > > > A2) grab "system hwe lock" and call vectored_exception_handler
> >> > > > A3) instantiate NullPointerException object
> >> > > > A4) set up throwing NullPointerExceptionObject in the register
> >> snapshot
> >> > > > A5) return from vectored_exception_handler release "system hwe
> >> lock"
> >> > > >
> >> > > > Let's next assume that garbage collection was started exactly when
> >> > > > thread A was in progress of running NullPointerException
> >> constructor.
> >> > > > Then, thread A will be suspended while still holding "system hwe
> >> lock".
> >> >
> >> > I see two bad things here. The first one is a violation of the pretty
> >> > known "rule". The rule is don't execute java methods under native
> >> > lock. That was discussed several times already. Another problem is
> >> > that two threads contend for the one lock while being in different
> >> > modes. In other words the first thread gets the lock in suspend
> >> > enabled state. The second thread tries to get the same lock in suspend
> >> > disabled state. But the first thread is already suspended by GC what
> >> > causes a deadlock. Thus it seems like another "rule" for me.
> >> >
> >> > Any native lock MUST be used either in suspend disabled or suspend
> >> > enabled regions. It is prohibited to go outside of the region with the
> >> > owned lock.
> >
> >
> > The above seems to make sense. It might be possible to to add asserts to
> > verify the rule is not violated.
> >
> > I agree with you. It is just not very obvious that the system kernel holds
> >> some internal lock when a thread is executing VEH.
> >
> >
> > hmm.... this conversation seems to be mixing DRLVM native code locks with
> > locks that are internal to the underlying OS (or OS provided user-level
> > libraries). Its important to sort out both issues. Gregory, can you
> > clarify?
>
> I didn't think I was mixing these locks. The deadlock which made us
> change VEH handler code occurred as a deadlock between kernel internal
> lock, and VM lock. Even if we create a facility which would allow to
> check (via assertion) the locked/unlocked state of VM locks, it won't
> help us when there are locks which we don't control, like in this case.
Seems like we mixing two diffrerent topics in one thread. Here is
another thread "[drlvm][threading] Native locks and thread suspension"
for discussing different deadlock scenarios...
Evgueni
>
> > It is windows specific and
> >> specific only to some windows versions. We know for sure that windows
> >> 2003
> >> server SP1 doesn't have this problem.
> >
> >
> >
> > I am not sure if it is documented anywhere. We've found the fact that this
> >> lock exists in a hard way.
> >>
> >> > Does the above make sense? Could we somehow ensure this rule with
> >> > assert statements?
> >>
> >> Yes it does. I've always wanted to have a function of Lock_Manager,
> >> something
> >> like bool is_locked_by_this_thread(). But asserts may be used only on the
> >> lock which are controlled by VM. Internal kernel or C runtime locks
> >> cannot
> >> be
> >> checked easily.
>
>
> --
> Gregory
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Gregory Shimansky <gs...@gmail.com>.
Weldon Washburn wrote:
> On 11/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
>> > > > A1) segfault occured
>> > > > A2) grab "system hwe lock" and call vectored_exception_handler
>> > > > A3) instantiate NullPointerException object
>> > > > A4) set up throwing NullPointerExceptionObject in the register
>> snapshot
>> > > > A5) return from vectored_exception_handler release "system hwe
>> lock"
>> > > >
>> > > > Let's next assume that garbage collection was started exactly when
>> > > > thread A was in progress of running NullPointerException
>> constructor.
>> > > > Then, thread A will be suspended while still holding "system hwe
>> lock".
>> >
>> > I see two bad things here. The first one is a violation of the pretty
>> > known "rule". The rule is don't execute java methods under native
>> > lock. That was discussed several times already. Another problem is
>> > that two threads contend for the one lock while being in different
>> > modes. In other words the first thread gets the lock in suspend
>> > enabled state. The second thread tries to get the same lock in suspend
>> > disabled state. But the first thread is already suspended by GC what
>> > causes a deadlock. Thus it seems like another "rule" for me.
>> >
>> > Any native lock MUST be used either in suspend disabled or suspend
>> > enabled regions. It is prohibited to go outside of the region with the
>> > owned lock.
>
>
> The above seems to make sense. It might be possible to to add asserts to
> verify the rule is not violated.
>
> I agree with you. It is just not very obvious that the system kernel holds
>> some internal lock when a thread is executing VEH.
>
>
> hmm.... this conversation seems to be mixing DRLVM native code locks with
> locks that are internal to the underlying OS (or OS provided user-level
> libraries). Its important to sort out both issues. Gregory, can you
> clarify?
I didn't think I was mixing these locks. The deadlock which made us
change VEH handler code occurred as a deadlock between kernel internal
lock, and VM lock. Even if we create a facility which would allow to
check (via assertion) the locked/unlocked state of VM locks, it won't
help us when there are locks which we don't control, like in this case.
> It is windows specific and
>> specific only to some windows versions. We know for sure that windows
>> 2003
>> server SP1 doesn't have this problem.
>
>
>
> I am not sure if it is documented anywhere. We've found the fact that this
>> lock exists in a hard way.
>>
>> > Does the above make sense? Could we somehow ensure this rule with
>> > assert statements?
>>
>> Yes it does. I've always wanted to have a function of Lock_Manager,
>> something
>> like bool is_locked_by_this_thread(). But asserts may be used only on the
>> lock which are controlled by VM. Internal kernel or C runtime locks
>> cannot
>> be
>> checked easily.
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Weldon Washburn <we...@gmail.com>.
On 11/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
> > > > A1) segfault occured
> > > > A2) grab "system hwe lock" and call vectored_exception_handler
> > > > A3) instantiate NullPointerException object
> > > > A4) set up throwing NullPointerExceptionObject in the register
> snapshot
> > > > A5) return from vectored_exception_handler release "system hwe lock"
> > > >
> > > > Let's next assume that garbage collection was started exactly when
> > > > thread A was in progress of running NullPointerException
> constructor.
> > > > Then, thread A will be suspended while still holding "system hwe
> lock".
> >
> > I see two bad things here. The first one is a violation of the pretty
> > known "rule". The rule is don't execute java methods under native
> > lock. That was discussed several times already. Another problem is
> > that two threads contend for the one lock while being in different
> > modes. In other words the first thread gets the lock in suspend
> > enabled state. The second thread tries to get the same lock in suspend
> > disabled state. But the first thread is already suspended by GC what
> > causes a deadlock. Thus it seems like another "rule" for me.
> >
> > Any native lock MUST be used either in suspend disabled or suspend
> > enabled regions. It is prohibited to go outside of the region with the
> > owned lock.
The above seems to make sense. It might be possible to to add asserts to
verify the rule is not violated.
I agree with you. It is just not very obvious that the system kernel holds
> some internal lock when a thread is executing VEH.
hmm.... this conversation seems to be mixing DRLVM native code locks with
locks that are internal to the underlying OS (or OS provided user-level
libraries). Its important to sort out both issues. Gregory, can you
clarify?
It is windows specific and
> specific only to some windows versions. We know for sure that windows 2003
> server SP1 doesn't have this problem.
I am not sure if it is documented anywhere. We've found the fact that this
> lock exists in a hard way.
>
> > Does the above make sense? Could we somehow ensure this rule with
> > assert statements?
>
> Yes it does. I've always wanted to have a function of Lock_Manager,
> something
> like bool is_locked_by_this_thread(). But asserts may be used only on the
> lock which are controlled by VM. Internal kernel or C runtime locks cannot
> be
> checked easily.
>
> --
> Gregory
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][classlib unit tests] iterative runs
Posted by Gregory Shimansky <gs...@gmail.com>.
On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
> > > A1) segfault occured
> > > A2) grab "system hwe lock" and call vectored_exception_handler
> > > A3) instantiate NullPointerException object
> > > A4) set up throwing NullPointerExceptionObject in the register snapshot
> > > A5) return from vectored_exception_handler release "system hwe lock"
> > >
> > > Let's next assume that garbage collection was started exactly when
> > > thread A was in progress of running NullPointerException constructor.
> > > Then, thread A will be suspended while still holding "system hwe lock".
>
> I see two bad things here. The first one is a violation of the pretty
> known "rule". The rule is don't execute java methods under native
> lock. That was discussed several times already. Another problem is
> that two threads contend for the one lock while being in different
> modes. In other words the first thread gets the lock in suspend
> enabled state. The second thread tries to get the same lock in suspend
> disabled state. But the first thread is already suspended by GC what
> causes a deadlock. Thus it seems like another "rule" for me.
>
> Any native lock MUST be used either in suspend disabled or suspend
> enabled regions. It is prohibited to go outside of the region with the
> owned lock.
I agree with you. It is just not very obvious that the system kernel holds
some internal lock when a thread is executing VEH. It is windows specific and
specific only to some windows versions. We know for sure that windows 2003
server SP1 doesn't have this problem.
I am not sure if it is documented anywhere. We've found the fact that this
lock exists in a hard way.
> Does the above make sense? Could we somehow ensure this rule with
> assert statements?
Yes it does. I've always wanted to have a function of Lock_Manager, something
like bool is_locked_by_this_thread(). But asserts may be used only on the
lock which are controlled by VM. Internal kernel or C runtime locks cannot be
checked easily.
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
> Salikh Zakirov wrote:
> > Evgueni Brevnov wrote:
> >> Agree! It seems like a mess for me as well. The most clean approach is
> >> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> >> native code.
> >
> > I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
> > XP, and it turned out to be related to the hardware exception handling.
>
> I can't believe we'll see this test running again :)
>
> > Since the fix will involve significant modifications to the file
> > vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
> > I can do this modification too.
>
> Good.
>
> > P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
> > Assume thread A handles NPE:
> >
> > A1) segfault occured
> > A2) grab "system hwe lock" and call vectored_exception_handler
> > A3) instantiate NullPointerException object
> > A4) set up throwing NullPointerExceptionObject in the register snapshot
> > A5) return from vectored_exception_handler release "system hwe lock"
> >
> > Let's next assume that garbage collection was started exactly when thread A
> > was in progress of running NullPointerException constructor. Then, thread A
> > will be suspended while still holding "system hwe lock".
I see two bad things here. The first one is a violation of the pretty
known "rule". The rule is don't execute java methods under native
lock. That was discussed several times already. Another problem is
that two threads contend for the one lock while being in different
modes. In other words the first thread gets the lock in suspend
enabled state. The second thread tries to get the same lock in suspend
disabled state. But the first thread is already suspended by GC what
causes a deadlock. Thus it seems like another "rule" for me.
Any native lock MUST be used either in suspend disabled or suspend
enabled regions. It is prohibited to go outside of the region with the
owned lock.
Does the above make sense? Could we somehow ensure this rule with
assert statements?
Thanks
Evgueni
> >
> > Another thread B at that moment may be blocked on a "system hwe lock",
> > and since this lock is system and not known to Thread Manager, it just
> > waits forever for thread B to reach a safepoint.
>
> This explains why this test doesn't hang on windows 2003 server SP1
> (without SP1 the test hangs). I've seen this problem with system locking
> some internal lock for VEH, and the fix for JVMTI is in HARMONY-1541.
>
> Probably all parts of exception/signal handling should be changed to
> this same trick - exit kernel to release the lock, and set EIP in
> register context to point to the real VM exceptions handler.
>
> --
> Gregory
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Gregory Shimansky <gs...@gmail.com>.
Salikh Zakirov wrote:
> Evgueni Brevnov wrote:
>> Agree! It seems like a mess for me as well. The most clean approach is
>> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
>> native code.
>
> I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
> XP, and it turned out to be related to the hardware exception handling.
I can't believe we'll see this test running again :)
> Since the fix will involve significant modifications to the file
> vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
> I can do this modification too.
Good.
> P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
> Assume thread A handles NPE:
>
> A1) segfault occured
> A2) grab "system hwe lock" and call vectored_exception_handler
> A3) instantiate NullPointerException object
> A4) set up throwing NullPointerExceptionObject in the register snapshot
> A5) return from vectored_exception_handler release "system hwe lock"
>
> Let's next assume that garbage collection was started exactly when thread A
> was in progress of running NullPointerException constructor. Then, thread A
> will be suspended while still holding "system hwe lock".
>
> Another thread B at that moment may be blocked on a "system hwe lock",
> and since this lock is system and not known to Thread Manager, it just
> waits forever for thread B to reach a safepoint.
This explains why this test doesn't hang on windows 2003 server SP1
(without SP1 the test hangs). I've seen this problem with system locking
some internal lock for VEH, and the fix for JVMTI is in HARMONY-1541.
Probably all parts of exception/signal handling should be changed to
this same trick - exit kernel to release the lock, and set EIP in
register context to point to the real VM exceptions handler.
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Salikh Zakirov <Sa...@Intel.com>.
Salikh Zakirov wrote:
> I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
> XP, and it turned out to be related to the hardware exception handling.
>
> Since the fix will involve significant modifications to the file
> vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
> I can do this modification too.
I'm sending my current state of the patch (well, series of 3 patches)
for interested parties to review.
However, these patches somewhat regress in functionality:
I still haven't figured out how to piggy-back on exception throw
to call JVMTI callback and to restore stack guard page.
(the commented out block at the end of nt_exception_filter.cpp was doing it
before fix).
Any ideas appreciated.
Re: [drlvm][classlib unit tests] iterative runs
Posted by Salikh Zakirov <Sa...@Intel.com>.
Evgueni Brevnov wrote:
> Agree! It seems like a mess for me as well. The most clean approach is
> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> native code.
I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
XP, and it turned out to be related to the hardware exception handling.
Since the fix will involve significant modifications to the file
vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
I can do this modification too.
P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
Assume thread A handles NPE:
A1) segfault occured
A2) grab "system hwe lock" and call vectored_exception_handler
A3) instantiate NullPointerException object
A4) set up throwing NullPointerExceptionObject in the register snapshot
A5) return from vectored_exception_handler release "system hwe lock"
Let's next assume that garbage collection was started exactly when thread A
was in progress of running NullPointerException constructor. Then, thread A
will be suspended while still holding "system hwe lock".
Another thread B at that moment may be blocked on a "system hwe lock",
and since this lock is system and not known to Thread Manager, it just
waits forever for thread B to reach a safepoint.
Re: [launcher] disable exception handler Was: [drlvm][classlib unit
tests] iterative runs
Posted by Tim Ellison <t....@gmail.com>.
Salikh Zakirov wrote:
> Evgueni Brevnov wrote:
>> The most clean approach is
>> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
>> native code. I would suggest to fix the problem in this way instead of
>> HARMONY-2285. Currently, the launcher installs its own exception
>> handler which blocks default exception handler. So if we wish to have
>> a debug dialog we need to disable launcher's handler somehow. Should
>> we discuss it in a new thread?
>
> Personally, I use the modified launcher with exception protection commented out
> all the time.
>
> I recollect vaguely that introducing command line flag for disabling exception
> handling in launcher was discussed and agreed upon, however, noone got to
> implement it yet.
>
> (The other "pending" task for launcher was moving it from luni module to
> jdktools -- also seems to have been agreed upon and then abandoned)
I think you are being unfair to say 'abandoned' -- we agree on lots of
things but only have time to implement some of them.
Everyone is welcome to suggest fixes and enhancements, and everyone is
equally welcome to help implement them. Raise a JIRA and attach a patch.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [launcher] disable exception handler Was: [drlvm][classlib unit
tests] iterative runs
Posted by Tim Ellison <t....@gmail.com>.
Evgueni Brevnov wrote:
> On 11/24/06, Alexey Varlamov <al...@gmail.com> wrote:
>> 2006/11/24, Salikh Zakirov <Sa...@intel.com>:
>> > Evgueni Brevnov wrote:
>> > > The most clean approach is
>> > > to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
>> > > native code. I would suggest to fix the problem in this way
>> instead of
>> > > HARMONY-2285. Currently, the launcher installs its own exception
>> > > handler which blocks default exception handler. So if we wish to have
>> > > a debug dialog we need to disable launcher's handler somehow. Should
>> > > we discuss it in a new thread?
>> >
>> > Personally, I use the modified launcher with exception protection
>> commented out
>> > all the time.
>>
>> Huh, me too :). Don't know, may be raising JIRA could speed up final
>> resolution?
>
> And me too :-)
Raising a JIRA - with a suggested patch - would speed it up :-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [launcher] disable exception handler Was: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/24/06, Alexey Varlamov <al...@gmail.com> wrote:
> 2006/11/24, Salikh Zakirov <Sa...@intel.com>:
> > Evgueni Brevnov wrote:
> > > The most clean approach is
> > > to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> > > native code. I would suggest to fix the problem in this way instead of
> > > HARMONY-2285. Currently, the launcher installs its own exception
> > > handler which blocks default exception handler. So if we wish to have
> > > a debug dialog we need to disable launcher's handler somehow. Should
> > > we discuss it in a new thread?
> >
> > Personally, I use the modified launcher with exception protection commented out
> > all the time.
>
> Huh, me too :). Don't know, may be raising JIRA could speed up final resolution?
And me too :-)
>
> >
> > I recollect vaguely that introducing command line flag for disabling exception
> > handling in launcher was discussed and agreed upon, however, noone got to
> > implement it yet.
> >
> > (The other "pending" task for launcher was moving it from luni module to
> > jdktools -- also seems to have been agreed upon and then abandoned)
> >
> >
>
Re: [launcher] disable exception handler Was: [drlvm][classlib unit tests] iterative runs
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/24, Salikh Zakirov <Sa...@intel.com>:
> Evgueni Brevnov wrote:
> > The most clean approach is
> > to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> > native code. I would suggest to fix the problem in this way instead of
> > HARMONY-2285. Currently, the launcher installs its own exception
> > handler which blocks default exception handler. So if we wish to have
> > a debug dialog we need to disable launcher's handler somehow. Should
> > we discuss it in a new thread?
>
> Personally, I use the modified launcher with exception protection commented out
> all the time.
Huh, me too :). Don't know, may be raising JIRA could speed up final resolution?
>
> I recollect vaguely that introducing command line flag for disabling exception
> handling in launcher was discussed and agreed upon, however, noone got to
> implement it yet.
>
> (The other "pending" task for launcher was moving it from luni module to
> jdktools -- also seems to have been agreed upon and then abandoned)
>
>
Re: [launcher] disable exception handler Was: [drlvm][classlib unit
tests] iterative runs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Salikh Zakirov wrote:
> Evgueni Brevnov wrote:
>> The most clean approach is
>> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
>> native code. I would suggest to fix the problem in this way instead of
>> HARMONY-2285. Currently, the launcher installs its own exception
>> handler which blocks default exception handler. So if we wish to have
>> a debug dialog we need to disable launcher's handler somehow. Should
>> we discuss it in a new thread?
>
> Personally, I use the modified launcher with exception protection commented out
> all the time.
>
> I recollect vaguely that introducing command line flag for disabling exception
> handling in launcher was discussed and agreed upon, however, noone got to
> implement it yet.
>
> (The other "pending" task for launcher was moving it from luni module to
> jdktools -- also seems to have been agreed upon and then abandoned)
There's lots of things to do. Things aren't abandoned. For example, I
haven't heard about class unloading fixes for DRLVM for a while, but
it's clearly not been abandoned...
geir
[launcher] disable exception handler Was: [drlvm][classlib unit tests]
iterative runs
Posted by Salikh Zakirov <Sa...@Intel.com>.
Evgueni Brevnov wrote:
> The most clean approach is
> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> native code. I would suggest to fix the problem in this way instead of
> HARMONY-2285. Currently, the launcher installs its own exception
> handler which blocks default exception handler. So if we wish to have
> a debug dialog we need to disable launcher's handler somehow. Should
> we discuss it in a new thread?
Personally, I use the modified launcher with exception protection commented out
all the time.
I recollect vaguely that introducing command line flag for disabling exception
handling in launcher was discussed and agreed upon, however, noone got to
implement it yet.
(The other "pending" task for launcher was moving it from luni module to
jdktools -- also seems to have been agreed upon and then abandoned)
Re: [drlvm][classlib unit tests] iterative runs
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 11/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
> Correction below
>
> Gregory Shimansky wrote:
> > On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
> >> Tatiana,
> >> That's great! Feel free to file JIRA issues about new problems.
> >>
> >> This is quite interesting that you haven't discovered
> >> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> >> failure using effectively the same revision as I. This makes me think
> >> that my problems can be local to my computer.
> >
> > The problem with this test appeared to be a regression after HARMONY-2006.
> > DRLVM started to halt of all unknown exceptions passing to VEH handler
> > when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH
> > handler is called in case of C++ exceptions too.
> >
> > Also it appeared that windows kernel uses exceptions inside of itself, so VEH
> > handler is called for some API functions which return an error, like in case
> > of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any
> > unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler.
>
> It should have been "EXCEPTION_CONTINUE_SEARCH" in this text, I pasted a
> wrong one from the code. This code was used to find a suitable handler
> (or show the error window) for the received exception.
>
> > Now it started to call DebugBreak in case when
> > UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
> >
> > Ivan offered a quick fix in HARMONY-2285, which calls this function only if
> > IS_ERROR [2] macro returns true for the exception code. The fix helped, and
> > now in interactive test runs when -Dvm.assert_dialog=true (default) tests
> > pass just as well as in non-interactive mode.
> >
> > I am still a bit unsure, why mess around with unknown exception codes, maybe
> > it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging
> > dialog will be open by the default NT handler.
Agree! It seems like a mess for me as well. The most clean approach is
to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
native code. I would suggest to fix the problem in this way instead of
HARMONY-2285. Currently, the launcher installs its own exception
handler which blocks default exception handler. So if we wish to have
a debug dialog we need to disable launcher's handler somehow. Should
we discuss it in a new thread?
Thanks
Evgueni
> >
> > [1]
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
> >
> > [2]
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
> >
>
>
> --
> Gregory
>
>
Re: [drlvm][classlib unit tests] iterative runs
Posted by Gregory Shimansky <gs...@gmail.com>.
Correction below
Gregory Shimansky wrote:
> On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
>> Tatiana,
>> That's great! Feel free to file JIRA issues about new problems.
>>
>> This is quite interesting that you haven't discovered
>> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
>> failure using effectively the same revision as I. This makes me think
>> that my problems can be local to my computer.
>
> The problem with this test appeared to be a regression after HARMONY-2006.
> DRLVM started to halt of all unknown exceptions passing to VEH handler
> when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH
> handler is called in case of C++ exceptions too.
>
> Also it appeared that windows kernel uses exceptions inside of itself, so VEH
> handler is called for some API functions which return an error, like in case
> of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any
> unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler.
It should have been "EXCEPTION_CONTINUE_SEARCH" in this text, I pasted a
wrong one from the code. This code was used to find a suitable handler
(or show the error window) for the received exception.
> Now it started to call DebugBreak in case when
> UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
>
> Ivan offered a quick fix in HARMONY-2285, which calls this function only if
> IS_ERROR [2] macro returns true for the exception code. The fix helped, and
> now in interactive test runs when -Dvm.assert_dialog=true (default) tests
> pass just as well as in non-interactive mode.
>
> I am still a bit unsure, why mess around with unknown exception codes, maybe
> it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging
> dialog will be open by the default NT handler.
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
>
> [2]
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
>
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
> Tatiana,
> That's great! Feel free to file JIRA issues about new problems.
>
> This is quite interesting that you haven't discovered
> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
> failure using effectively the same revision as I. This makes me think
> that my problems can be local to my computer.
The problem with this test appeared to be a regression after HARMONY-2006.
DRLVM started to halt of all unknown exceptions passing to VEH handler
when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH
handler is called in case of C++ exceptions too.
Also it appeared that windows kernel uses exceptions inside of itself, so VEH
handler is called for some API functions which return an error, like in case
of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any
unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler.
Now it started to call DebugBreak in case when
UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
Ivan offered a quick fix in HARMONY-2285, which calls this function only if
IS_ERROR [2] macro returns true for the exception code. The fix helped, and
now in interactive test runs when -Dvm.assert_dialog=true (default) tests
pass just as well as in non-interactive mode.
I am still a bit unsure, why mess around with unknown exception codes, maybe
it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging
dialog will be open by the default NT handler.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
--
Gregory
Re: [drlvm][classlib unit tests] iterative runs
Posted by Alexei Fedotov <al...@gmail.com>.
Tatiana,
That's great! Feel free to file JIRA issues about new problems.
This is quite interesting that you haven't discovered
org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
failure using effectively the same revision as I. This makes me think
that my problems can be local to my computer.
--
Thank you,
Alexei
On 11/21/06, tatyana doubtsova <ta...@gmail.com> wrote:
> Hello,
>
> I've run classlib unit tests on Win XP in Other VM mode 50 times for each
> module in order to reveal sporadic failures.
>
>
>
> The script is
>
>
>
> #!sh
>
> cat modulesList | while read moduleName; do
>
> A=0
>
> while [ "$A" -lt "50" ]; do
>
> echo ITERATION $A
>
> ant -
> Dtest.jre.home=c:/users/tdoubtso/harmony/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre\
>
> -Dbuild.module=$moduleName -
> Dhy.test.forkmode=perTest \
>
> test 2>&1 | tee log_${moduleName}_${A}.txt
>
> cp -rf build/test_report build/test_report.${moduleName}_${A}
>
> A=`expr $A + 1`
>
> done
>
> done
>
>
>
>
>
> $ cat moduleList
>
>
>
> accessibility
>
> archive
>
> auth
>
> awt
>
> beans
>
> crypto
>
> instrument
>
> jndi
>
> lang-management
>
> logging
>
> luni
>
> math
>
> nio
>
> nio_char
>
> prefs
>
> print
>
> regex
>
> rmi
>
> security
>
> sound
>
> sql
>
> swing
>
> text
>
> tools
>
> x-net
>
>
>
>
>
> I've observed the following failures on svn=r476124
>
>
>
>
>
> *Module*
>
> *Test*
>
> *Number of failures*
>
> *issue*
>
> luni
>
> org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest
>
> 50 out of 50
>
> 1879 <http://issues.apache.org/jira/browse/HARMONY-1879>, updated
>
> luni
>
> tests.api.java.net.InetAddressTest
>
> 50 out of 50
>
> Test was eliminated from repository after Novenber,17
>
> prefs
>
> org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest
>
> 50 out of 50
>
> 1751 <http://issues.apache.org/jira/browse/HARMONY-1751>
>
> swing
>
> javax.swing.text.WrappedPlainView_SimpleTest
>
> 1 time out of 50
>
> 1)
>
> swing
>
> javax.swing.SpinnerDateModelTest
>
> 35 times out of 50
>
> 2)
>
>
>
>
> 1). Eror
>
> Timeout occurred
>
> junit.framework.AssertionFailedError: Timeout occurred
>
>
>
> 2). Failure
>
> expected:<0> but was:<7>
>
> junit.framework.AssertionFailedError: expected:<0> but was:<7> at
> javax.swing.SpinnerDateModelTest.testSpinnerDateModel(
> SpinnerDateModelTest.java:59) at
> java.lang.reflect.VMReflection.invokeMethod(Native
> Method) at javax.swing.BasicSwingTestCase.runBareSuper(
> BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase.runBareImpl(
> BasicSwingTestCase.java) at javax.swing.BasicSwingTestCase$1.run(
> BasicSwingTestCase.java) at java.lang.Thread.run(Unknown Source)
>
>
>
> 2070 <http://issues.apache.org/jira/browse/HARMONY-2070> was not reproduced
> during this test run
>
>
>
> I can't reproduce 1) and 2) today on svn = r477507
>
>
>
> I've excluded failed tests and restarted multiple test run on Win XP in
> order to make sure there is no other sporadic failures.
>
> Also I'm going to start the multiple classlib tests run on SUSE 9
>
>
>
>
>
> To extract the results I've used commands:
>
> cd classlib/trunk/buid
>
> # find errors
>
> find . -name *Test.xml -exec grep -l "<testsuite errors=\"[1-9]*\" " {} \; >
> ERRORS
>
> # find failures
>
> find . -name *Test.xml -exec grep -l "<testsuite errors=\"*\"
> failures=\"[1-9]*\"" {} \; > FAILURES
>
> find . -type f -size 0 | grep *.xml > ZERO_LENGTH
>
>
>
> Also I've compared the number of files in test_report directories:
>
> #!sh
>
> cat modulesList | while read moduleName; do
>
> echo $moduleName
>
> A=1
>
> while [ "$A" -lt "51" ]; do
>
> L=`ls -1 build/test_report.${moduleName}_${A} | grep xml | wc
> -l`
>
> echo build/test_report.${moduleName}_${A} $L >>
> test_report_length
>
> A=`expr $A + 1`
>
> done
> done
>
> Thanks,
> Tanya
>
>