You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Fedotov, Alexei A" <al...@intel.com> on 2006/11/05 18:51:36 UTC
RE: [drlvm] [testing] Excluding commit tests until the problem is fixed
Rana, Pavel (Afremov), All,
Geir's comment on r443504 (fix for
http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
bit support, JVMTI improvements) reads:
> 1) Stack overflow exception stuff is broken. I had to remove the
assert
> in signals_ia32.cpp line 336. Rana knows and will look. I also
> disabled the StackTest.
I have noticed that the patch added a new function
exn_raise_by_name_internal which fails on the first invocation checking
an assertion about thread state, see
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
crashes DRLVM.
I also have noticed that this function is called to create
java.lang.StackOverflowError.
Could you help me to understand the current status of the problem?
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-----Original Message-----
>From: Rana Dasgupta [mailto:rdasgupt@gmail.com]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>I fixed the StackOverflow functionality problem by going back and
mapping
>all pages ( guard, alternate stack ) meticulously before trying to
protect
>them. I think we should have done this in the first place. I also
cleaned
>up the previous initialization workarounds and asserts Geir and I had
>discussed on the JIRA. The Stacktest and all other stack related tests
now
>pass.
>
>I'll submit the patch against 1786 in the next few hours after running
>acceptance tests.
>
>Rana
>
>
>
>> On 10/16/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> >
>> >
>> >
>> > On 10/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
>> > >
>> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> > > >> I tried to put some back. StackTest still doesn't work. It's
>hard
>> > > to
>> > > >> believe... so I gave up and just kept going :)
>> > >
>> > > >I wonder if the test or the implementation are wrong. Maybe
someone
>> > > who added
>> > > >the test initially could know the answer.
>> >
>> >
>> >
>> > There is nothing wrong with the stacktest test itself. The
>> > > implementation is not quite 100%complete( I think ), but has
enough
>> > > functionality and the test passes on Windows. On Linux, it fails.
I
>am not
>> > > sure if this is a regression, or if this ever worked. There is a
JIRA
>issue
>> > > 1786. In summary, memory protection setup for the guard page
fails on
>the
>> > > main thread(only). So the guard does not work and the overflow is
not
>> > > detected.
>> >
>> >
>> > mprotect fails with an ENOMEM which is either a mapping failure
or a
>> > kernel failure. mprotect() has some known flakiness it seems, as
per
>> > literature.
>> >
>> > The basic implementation on Linux is sound. There are secondary
>design
>> > issues,but we can only get to them later after we have figured out
why
>the
>> > guard setup fails on the main thread.
>> >
>> >
>> >
>> >
>>
>
>>
>>
>>
>>
>>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Alexey Varlamov <al...@gmail.com>.
+1
I like this approach too - more flexible than current.
2006/11/16, Vladimir Ivanov <iv...@gmail.com>:
> On 11/16/06, Tim Ellison <t....@gmail.com> wrote:
> >
> > Vladimir Ivanov wrote:
> > > As part of solution for this issue the
> > > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> > > created.
> > >
> > > I suggest using the separate exclude list for each platform. I hope in
> > this
> > > case the test enabling for the different platforms will be easy. Please,
> > > look at it.
> > >
> > > Any comments are welcome :)
> >
> > Maybe a dumb question by why hard-code
> >
> > <property name="hy.test.vm.name" value="ibm" />
> >
> > Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
> > a short form suitable as a directory name?
>
>
>
> Actually, this property is defined before the test run by Ant's VM. In my
> case it is
>
> 'Java HotSpot(TM) Client VM'.
>
>
>
> As variant, the java from 'test.jre.home' may be run with "-version" option
> and output may be parsed and mapped to some value. In this case all Harmony
> VM should support this option and print different messages. Is it OK?
>
>
>
> I suggest implementing version with hard coded vm name and than extend it by
> auto-detecting capability.
>
>
>
> Thanks, Vladimir
>
>
>
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by Tim Ellison <t....@gmail.com>.
Vladimir Ivanov wrote:
> As variant, the java from 'test.jre.home' may be run with "-version"
> option and output may be parsed and mapped to some value. In this
> case all Harmony VM should support this option and print different
> messages. Is it OK?
>
> I suggest implementing version with hard coded vm name and than
> extend it by auto-detecting capability.
Sure give it a try and let us know what it takes.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 11/16/06, Tim Ellison <t....@gmail.com> wrote:
>
> Vladimir Ivanov wrote:
> > As part of solution for this issue the
> > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> > created.
> >
> > I suggest using the separate exclude list for each platform. I hope in
> this
> > case the test enabling for the different platforms will be easy. Please,
> > look at it.
> >
> > Any comments are welcome :)
>
> Maybe a dumb question by why hard-code
>
> <property name="hy.test.vm.name" value="ibm" />
>
> Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
> a short form suitable as a directory name?
Actually, this property is defined before the test run by Ant's VM. In my
case it is
'Java HotSpot(TM) Client VM'.
As variant, the java from 'test.jre.home' may be run with "-version" option
and output may be parsed and mapped to some value. In this case all Harmony
VM should support this option and print different messages. Is it OK?
I suggest implementing version with hard coded vm name and than extend it by
auto-detecting capability.
Thanks, Vladimir
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by Tim Ellison <t....@gmail.com>.
Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)
Maybe a dumb question by why hard-code
<property name="hy.test.vm.name" value="ibm" />
Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
a short form suitable as a directory name?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I like this approach.
+1
(it's exactly how I would have done it. :)
Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)
>
>
>
> Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>>
>> Pavel, you are correct. Rana, sorry for confusion. Both issues block
>> passing class library unit tests.
>>
>> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>> Unhandled exception in java.exe while java.util.jar module tests
>> execution
>>
>> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>>
>> I've used a debugger and caught an assert in
>> exn_raise_by_name_internal for the second one. The first one contains
>> three diffrent issues, and I cannot say where exactly the problem is.
>>
>> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>> >
>> > Alexei, is it correct? If not, could you clarify the point about
>> > exn_raise_by_name_internal in your initial letter, please?
>> >
>> >
>> > Pavel Afremov.
>> >
>> >
>> > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > >
>> > > OK thanks Pavel, I'll try the patch today.
>> > >
>> > > Rana
>> > >
>> > >
>> > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>> > > >
>> > > > Hi Rana.
>> > > >
>> > > >
>> > > >
>> > > > I extend guard region as work around. It's only one way, which
>> "fix"
>> SOE
>> > > > on
>> > > > my SuSE Linux, without potential regression of your fix. On my
>> Linux
>>
>> > > > machine
>> > > > violation access signals happen one page before protected page on
>> the
>> > > > stack.
>> > > > It's it.
>> > > >
>> > > >
>> > > >
>> > > > I ran all tests, and everything was OK. But strange misprint was
>> fount
>> > > in
>> > > > the new test.
>> > > >
>> > > > So I attach new fixed patch.
>> > > >
>> > > >
>> > > >
>> > > > Pavel Afremov.
>> > > >
>> > > >
>> > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > >
>> > > > > Though I tried several times, I could not repro 2070 or Alexey's
>> > > > specific
>> > > > > problems. The test attached to 2018 repros, and that I think is
>> > > enough.
>> > > > >
>> > > > > Pavel,
>> > > > > 1. The patch looks good, but I could not apply and try it since
>> my
>> > > > Linux
>> > > > > box is down.
>> > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
>> classlib )?
>>
>> > > Since
>> > > > > this fully turns on lazy exceptions, we need to ensure that all
>> tests
>> > > > > pass,
>> > > > > or at least have identical behaviour before and after the pacth.
>> > > > > 3. Adding a finalizer based stack test to smoke is a good idea.
>> > > > > 4. On Linux you extend the guard region up ( or down whatever )
>> by a
>> > > > > page. Did you find a good reason for it, or is this just being
>> > > careful?
>> > > > >
>> > > > > Rana
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> > > > > >
>> > > > > > Rana,
>> > > > > >
>> > > > > > Everything is correct in you description, but it looks like
>> that
>> *
>> > > > > > HARMONY-2018* <
>> https://issues.apache.org/jira/browse/HARMONY-2018>
>> > > > > should
>> > > > > > fix described bug. I think Alexei will have a chance to check
>> it.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Thank you.
>> > > > > >
>> > > > > > Pavel Afremov.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>> --
>> Thank you,
>> Alexei
>>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Vladimir Ivanov <iv...@gmail.com>.
Issue 2197 was updated to exclude test by the simplest way (very simple
exclude files).
The next step will be looking through the issue 263. I'll try it.
It will fine if somebody take care about issue 2197 (exclude files for
win/lnx on x86 for IBM and DRl VMs).
Thanks, Vladimir
On 11/17/06, Alexei Zakharov <al...@gmail.com> wrote:
>
> Hi Vladimir,
>
> It seems everybody likes this approach. In that case, I have another
> idea for exclude lists. Can't we go further and extend the current
> exclude list functionality a bit more? And forget about TestNG and
> friends for a while I mean.
>
> For example, we can put exclude lists into something like:
>
> exclude.xml:
> ---
> <exclude-list>
> <!-- exclude only particular tests -->
> <class name="org.apache.harmony.luni.test.java.io.MyTest">
> <test name="testConstructor11"/>
> <test name="testMyMethodObjectObjectString_HY1234"/>
> </class>
> <!-- exclude all tests -->
> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
> includeAll="true"/>
> ...
> </exclude-list>
>
> exclude.linux.drlvm.xml:
> ---
> <exclude-list>
> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
> <test name="testLinuxHang_my"/>
> </class>
> </exclude-list>
>
> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
> controller test suite by ant. By the controller test suite I mean the
> java class that knows how to parse the above files (using simple SAX
> parser for example - it is easy, I can help if needed) and implements
> junit TestSuite model to get fine-grained control over the testing
> process.
>
> IMHO this can be a nice solution for now. It's more powerful since it
> allows to exclude individual tests rather that whole classes. What do
> you think?
>
> Thanks,
>
>
> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> > Seems, we says about different things :)
> >
> > First of all, we have no TestNG (or other harness) yet but we need now
> > different exclude lists for different platforms.
> >
> > Also, in my vision these exclude-lists are like a buffer before we mark
> test
> > by correct tags.
> > When the test fails on some platform we update the corresponding x-list
> and
> > investigate this failure.
> > As the result of investigation we mark the test or fix it.
> >
> > Thanks, Vladimir
> >
> >
> > On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
> > >
> > > Things become more and more complicated. Can anyone say why we
> > > rejected to use TestSuites for this purpose from the very beginning?
> > > Well, I can't say I am against using xml lists here. But the next step
> > > will be to keep list of individual failing test methods in the xml
> > > file. Then to create separate xml lists for api and impl tests and so
> > > on. If we can't run original TestNG on Harmony then we invent it by
> > > ourselves. :-)
> > >
> > > Thanks,
> > >
> > > 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> > > > As part of solution for this issue the
> > > > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197>
> was
> > > > created.
> > > >
> > > > I suggest using the separate exclude list for each platform. I hope
> in
> > > this
> > > > case the test enabling for the different platforms will be easy.
> Please,
> > > > look at it.
> > > >
> > > > Any comments are welcome :)
> > > >
> > > >
> > > >
> > > > Thanks, Vladimir
> > > >
> > > >
> > > > On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
> > > > >
> > > > > Pavel, you are correct. Rana, sorry for confusion. Both issues
> block
> > > > > passing class library unit tests.
> > > > >
> > > > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > > > Unhandled exception in java.exe while java.util.jar module tests
> > > > > execution
> > > > >
> > > > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > > > >
> > > > > I've used a debugger and caught an assert in
> > > > > exn_raise_by_name_internal for the second one. The first one
> contains
> > > > > three diffrent issues, and I cannot say where exactly the problem
> is.
> > > > >
> > > > > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > > > >
> > > > > > Alexei, is it correct? If not, could you clarify the point about
> > > > > > exn_raise_by_name_internal in your initial letter, please?
> > > > > >
> > > > > >
> > > > > > Pavel Afremov.
> > > > > >
> > > > > >
> > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > >
> > > > > > > OK thanks Pavel, I'll try the patch today.
> > > > > > >
> > > > > > > Rana
> > > > > > >
> > > > > > >
> > > > > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Rana.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I extend guard region as work around. It's only one way,
> which
> > > "fix"
> > > > > SOE
> > > > > > > > on
> > > > > > > > my SuSE Linux, without potential regression of your fix. On
> my
> > > Linux
> > > > >
> > > > > > > > machine
> > > > > > > > violation access signals happen one page before protected
> page
> > > on
> > > > > the
> > > > > > > > stack.
> > > > > > > > It's it.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I ran all tests, and everything was OK. But strange misprint
> was
> > > > > fount
> > > > > > > in
> > > > > > > > the new test.
> > > > > > > >
> > > > > > > > So I attach new fixed patch.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Pavel Afremov.
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Though I tried several times, I could not repro 2070 or
> > > Alexey's
> > > > > > > > specific
> > > > > > > > > problems. The test attached to 2018 repros, and that I
> think
> > > is
> > > > > > > enough.
> > > > > > > > >
> > > > > > > > > Pavel,
> > > > > > > > > 1. The patch looks good, but I could not apply and try
> it
> > > since
> > > > > my
> > > > > > > > Linux
> > > > > > > > > box is down.
> > > > > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
> > > classlib )?
> > > > >
> > > > > > > Since
> > > > > > > > > this fully turns on lazy exceptions, we need to ensure
> that
> > > all
> > > > > tests
> > > > > > > > > pass,
> > > > > > > > > or at least have identical behaviour before and after the
> > > pacth.
> > > > > > > > > 3. Adding a finalizer based stack test to smoke is a
> good
> > > idea.
> > > > > > > > > 4. On Linux you extend the guard region up ( or down
> > > whatever )
> > > > > by a
> > > > > > > > > page. Did you find a good reason for it, or is this just
> being
> > > > > > > careful?
> > > > > > > > >
> > > > > > > > > Rana
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
> wrote:
> > > > > > > > > >
> > > > > > > > > > Rana,
> > > > > > > > > >
> > > > > > > > > > Everything is correct in you description, but it looks
> like
> > > that
> > > > > *
> > > > > > > > > > HARMONY-2018* <
> > > > > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > > > > should
> > > > > > > > > > fix described bug. I think Alexei will have a chance to
> > > check
> > > > > it.
>
>
>
> --
> Alexei Zakharov,
> Intel Enterprise Solutions Software Division
>
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Fedotov wrote:
> Do we have a best practice to link an exclusion to the reason? Are we
> intended to use svn blame for each line which contain <exclude>? Is it
> better to put comments right into the file near exludes? Thoughts?
What I meant by my comment is that I'm interested in seeing excludes in
external files, which can then be organized by platform, and have that
information used at the high-level in ant. So for that existing JIRA,
reusing code for managing exclude lists is a good idea, but I'm still
fairly resistant to the idea of tying ourselves closer to junit.
As for info.... not a bad idea... yeah, it might be good to place info
in comments in the exclude file, even if it's as simple as a JIRA entry
id. That way, if you want to see what's excluded, you can just look in
that file, and "why" is there too...
geir
>
> On 11/17/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> I spoke too soon - do you mean reusing the code for managing the exclude
>> lists?
>>
>> geir
>>
>>
>> Geir Magnusson Jr. wrote:
>> >
>> >
>> > Tim Ellison wrote:
>> >> Before you go off writing more code, just take a moment to look at
>> >> HARMONY-263 and tell us what you think of it.
>> >
>> > It ties us to JUnit. Doesn't moving the exclude list upwards give us
>> > more freedom?
>> >
>> > geir
>> >
>> >>
>> >> Thanks
>> >> Tim
>> >>
>> >> Alexei Zakharov wrote:
>> >>> Hi Vladimir,
>> >>>
>> >>> It seems everybody likes this approach. In that case, I have another
>> >>> idea for exclude lists. Can't we go further and extend the current
>> >>> exclude list functionality a bit more? And forget about TestNG and
>> >>> friends for a while I mean.
>> >>>
>> >>> For example, we can put exclude lists into something like:
>> >>>
>> >>> exclude.xml:
>> >>> ---
>> >>> <exclude-list>
>> >>> <!-- exclude only particular tests -->
>> >>> <class name="org.apache.harmony.luni.test.java.io.MyTest">
>> >>> <test name="testConstructor11"/>
>> >>> <test name="testMyMethodObjectObjectString_HY1234"/>
>> >>> </class>
>> >>> <!-- exclude all tests -->
>> >>> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
>> >>> includeAll="true"/>
>> >>> ...
>> >>> </exclude-list>
>> >>>
>> >>> exclude.linux.drlvm.xml:
>> >>> ---
>> >>> <exclude-list>
>> >>> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
>> >>> <test name="testLinuxHang_my"/>
>> >>> </class>
>> >>> </exclude-list>
>> >>>
>> >>> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
>> >>> controller test suite by ant. By the controller test suite I mean the
>> >>> java class that knows how to parse the above files (using simple SAX
>> >>> parser for example - it is easy, I can help if needed) and implements
>> >>> junit TestSuite model to get fine-grained control over the testing
>> >>> process.
>> >>>
>> >>> IMHO this can be a nice solution for now. It's more powerful since it
>> >>> allows to exclude individual tests rather that whole classes. What do
>> >>> you think?
>> >>>
>> >>> Thanks,
>> >>>
>> >>>
>> >>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>> >>>> Seems, we says about different things :)
>> >>>>
>> >>>> First of all, we have no TestNG (or other harness) yet but we
>> need now
>> >>>> different exclude lists for different platforms.
>> >>>>
>> >>>> Also, in my vision these exclude-lists are like a buffer before we
>> >>>> mark test
>> >>>> by correct tags.
>> >>>> When the test fails on some platform we update the corresponding
>> >>>> x-list and
>> >>>> investigate this failure.
>> >>>> As the result of investigation we mark the test or fix it.
>> >>>>
>> >>>> Thanks, Vladimir
>> >>>>
>> >>>>
>> >>>> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>> >>>>> Things become more and more complicated. Can anyone say why we
>> >>>>> rejected to use TestSuites for this purpose from the very
>> beginning?
>> >>>>> Well, I can't say I am against using xml lists here. But the
>> next step
>> >>>>> will be to keep list of individual failing test methods in the xml
>> >>>>> file. Then to create separate xml lists for api and impl tests
>> and so
>> >>>>> on. If we can't run original TestNG on Harmony then we invent it by
>> >>>>> ourselves. :-)
>> >>>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>> >>>>>> As part of solution for this issue the
>> >>>>>>
>> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
>> >>>>>> created.
>> >>>>>>
>> >>>>>> I suggest using the separate exclude list for each platform. I
>> >>>> hope in
>> >>>>> this
>> >>>>>> case the test enabling for the different platforms will be easy.
>> >>>> Please,
>> >>>>>> look at it.
>> >>>>>>
>> >>>>>> Any comments are welcome :)
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Thanks, Vladimir
>> >>>>>>
>> >>>>>>
>> >>>>>> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>> >>>>>>> Pavel, you are correct. Rana, sorry for confusion. Both issues
>> >>>> block
>> >>>>>>> passing class library unit tests.
>> >>>>>>>
>> >>>>>>> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>> >>>>>>> Unhandled exception in java.exe while java.util.jar module tests
>> >>>>>>> execution
>> >>>>>>>
>> >>>>>>> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>> >>>>>>> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>> >>>>>>>
>> >>>>>>> I've used a debugger and caught an assert in
>> >>>>>>> exn_raise_by_name_internal for the second one. The first one
>> >>>> contains
>> >>>>>>> three diffrent issues, and I cannot say where exactly the
>> >>>> problem is.
>> >>>>>>> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> >>>>>>>> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>> >>>>>>>>
>> >>>>>>>> Alexei, is it correct? If not, could you clarify the point about
>> >>>>>>>> exn_raise_by_name_internal in your initial letter, please?
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Pavel Afremov.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> >>>>>>>>> OK thanks Pavel, I'll try the patch today.
>> >>>>>>>>>
>> >>>>>>>>> Rana
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>> >>>>>>>>>> Hi Rana.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> I extend guard region as work around. It's only one way,
>> >>>> which
>> >>>>> "fix"
>> >>>>>>> SOE
>> >>>>>>>>>> on
>> >>>>>>>>>> my SuSE Linux, without potential regression of your fix.
>> >>>> On my
>> >>>>> Linux
>> >>>>>>>>>> machine
>> >>>>>>>>>> violation access signals happen one page before protected
>> >>>> page
>> >>>>> on
>> >>>>>>> the
>> >>>>>>>>>> stack.
>> >>>>>>>>>> It's it.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> I ran all tests, and everything was OK. But strange
>> >>>> misprint was
>> >>>>>>> fount
>> >>>>>>>>> in
>> >>>>>>>>>> the new test.
>> >>>>>>>>>>
>> >>>>>>>>>> So I attach new fixed patch.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Pavel Afremov.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> >>>>>>>>>>> Though I tried several times, I could not repro 2070 or
>> >>>>> Alexey's
>> >>>>>>>>>> specific
>> >>>>>>>>>>> problems. The test attached to 2018 repros, and that I
>> >>>> think
>> >>>>> is
>> >>>>>>>>> enough.
>> >>>>>>>>>>> Pavel,
>> >>>>>>>>>>> 1. The patch looks good, but I could not apply and try it
>> >>>>> since
>> >>>>>>> my
>> >>>>>>>>>> Linux
>> >>>>>>>>>>> box is down.
>> >>>>>>>>>>> 2. Did you run all tests ( smoke, cuint, kernel, and
>> >>>>> classlib )?
>> >>>>>>>>> Since
>> >>>>>>>>>>> this fully turns on lazy exceptions, we need to ensure that
>> >>>>> all
>> >>>>>>> tests
>> >>>>>>>>>>> pass,
>> >>>>>>>>>>> or at least have identical behaviour before and after the
>> >>>>> pacth.
>> >>>>>>>>>>> 3. Adding a finalizer based stack test to smoke is a good
>> >>>>> idea.
>> >>>>>>>>>>> 4. On Linux you extend the guard region up ( or down
>> >>>>> whatever )
>> >>>>>>> by a
>> >>>>>>>>>>> page. Did you find a good reason for it, or is this just
>> >>>> being
>> >>>>>>>>> careful?
>> >>>>>>>>>>> Rana
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
>> >>>> wrote:
>> >>>>>>>>>>>> Rana,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Everything is correct in you description, but it looks
>> >>>> like
>> >>>>> that
>> >>>>>>> *
>> >>>>>>>>>>>> HARMONY-2018* <
>> >>>>>>> https://issues.apache.org/jira/browse/HARMONY-2018>
>> >>>>>>>>>>> should
>> >>>>>>>>>>>> fix described bug. I think Alexei will have a chance to
>> >>>>> check
>> >>>>>>> it.
>> >>>
>> >>>
>> >>
>> >
>>
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Alexei Fedotov <al...@gmail.com>.
Do we have a best practice to link an exclusion to the reason? Are we
intended to use svn blame for each line which contain <exclude>? Is it
better to put comments right into the file near exludes? Thoughts?
On 11/17/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I spoke too soon - do you mean reusing the code for managing the exclude
> lists?
>
> geir
>
>
> Geir Magnusson Jr. wrote:
> >
> >
> > Tim Ellison wrote:
> >> Before you go off writing more code, just take a moment to look at
> >> HARMONY-263 and tell us what you think of it.
> >
> > It ties us to JUnit. Doesn't moving the exclude list upwards give us
> > more freedom?
> >
> > geir
> >
> >>
> >> Thanks
> >> Tim
> >>
> >> Alexei Zakharov wrote:
> >>> Hi Vladimir,
> >>>
> >>> It seems everybody likes this approach. In that case, I have another
> >>> idea for exclude lists. Can't we go further and extend the current
> >>> exclude list functionality a bit more? And forget about TestNG and
> >>> friends for a while I mean.
> >>>
> >>> For example, we can put exclude lists into something like:
> >>>
> >>> exclude.xml:
> >>> ---
> >>> <exclude-list>
> >>> <!-- exclude only particular tests -->
> >>> <class name="org.apache.harmony.luni.test.java.io.MyTest">
> >>> <test name="testConstructor11"/>
> >>> <test name="testMyMethodObjectObjectString_HY1234"/>
> >>> </class>
> >>> <!-- exclude all tests -->
> >>> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
> >>> includeAll="true"/>
> >>> ...
> >>> </exclude-list>
> >>>
> >>> exclude.linux.drlvm.xml:
> >>> ---
> >>> <exclude-list>
> >>> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
> >>> <test name="testLinuxHang_my"/>
> >>> </class>
> >>> </exclude-list>
> >>>
> >>> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
> >>> controller test suite by ant. By the controller test suite I mean the
> >>> java class that knows how to parse the above files (using simple SAX
> >>> parser for example - it is easy, I can help if needed) and implements
> >>> junit TestSuite model to get fine-grained control over the testing
> >>> process.
> >>>
> >>> IMHO this can be a nice solution for now. It's more powerful since it
> >>> allows to exclude individual tests rather that whole classes. What do
> >>> you think?
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> >>>> Seems, we says about different things :)
> >>>>
> >>>> First of all, we have no TestNG (or other harness) yet but we need now
> >>>> different exclude lists for different platforms.
> >>>>
> >>>> Also, in my vision these exclude-lists are like a buffer before we
> >>>> mark test
> >>>> by correct tags.
> >>>> When the test fails on some platform we update the corresponding
> >>>> x-list and
> >>>> investigate this failure.
> >>>> As the result of investigation we mark the test or fix it.
> >>>>
> >>>> Thanks, Vladimir
> >>>>
> >>>>
> >>>> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
> >>>>> Things become more and more complicated. Can anyone say why we
> >>>>> rejected to use TestSuites for this purpose from the very beginning?
> >>>>> Well, I can't say I am against using xml lists here. But the next step
> >>>>> will be to keep list of individual failing test methods in the xml
> >>>>> file. Then to create separate xml lists for api and impl tests and so
> >>>>> on. If we can't run original TestNG on Harmony then we invent it by
> >>>>> ourselves. :-)
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> >>>>>> As part of solution for this issue the
> >>>>>> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> >>>>>> created.
> >>>>>>
> >>>>>> I suggest using the separate exclude list for each platform. I
> >>>> hope in
> >>>>> this
> >>>>>> case the test enabling for the different platforms will be easy.
> >>>> Please,
> >>>>>> look at it.
> >>>>>>
> >>>>>> Any comments are welcome :)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thanks, Vladimir
> >>>>>>
> >>>>>>
> >>>>>> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
> >>>>>>> Pavel, you are correct. Rana, sorry for confusion. Both issues
> >>>> block
> >>>>>>> passing class library unit tests.
> >>>>>>>
> >>>>>>> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> >>>>>>> Unhandled exception in java.exe while java.util.jar module tests
> >>>>>>> execution
> >>>>>>>
> >>>>>>> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> >>>>>>> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >>>>>>>
> >>>>>>> I've used a debugger and caught an assert in
> >>>>>>> exn_raise_by_name_internal for the second one. The first one
> >>>> contains
> >>>>>>> three diffrent issues, and I cannot say where exactly the
> >>>> problem is.
> >>>>>>> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> >>>>>>>> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> >>>>>>>>
> >>>>>>>> Alexei, is it correct? If not, could you clarify the point about
> >>>>>>>> exn_raise_by_name_internal in your initial letter, please?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Pavel Afremov.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >>>>>>>>> OK thanks Pavel, I'll try the patch today.
> >>>>>>>>>
> >>>>>>>>> Rana
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> >>>>>>>>>> Hi Rana.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I extend guard region as work around. It's only one way,
> >>>> which
> >>>>> "fix"
> >>>>>>> SOE
> >>>>>>>>>> on
> >>>>>>>>>> my SuSE Linux, without potential regression of your fix.
> >>>> On my
> >>>>> Linux
> >>>>>>>>>> machine
> >>>>>>>>>> violation access signals happen one page before protected
> >>>> page
> >>>>> on
> >>>>>>> the
> >>>>>>>>>> stack.
> >>>>>>>>>> It's it.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I ran all tests, and everything was OK. But strange
> >>>> misprint was
> >>>>>>> fount
> >>>>>>>>> in
> >>>>>>>>>> the new test.
> >>>>>>>>>>
> >>>>>>>>>> So I attach new fixed patch.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Pavel Afremov.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >>>>>>>>>>> Though I tried several times, I could not repro 2070 or
> >>>>> Alexey's
> >>>>>>>>>> specific
> >>>>>>>>>>> problems. The test attached to 2018 repros, and that I
> >>>> think
> >>>>> is
> >>>>>>>>> enough.
> >>>>>>>>>>> Pavel,
> >>>>>>>>>>> 1. The patch looks good, but I could not apply and try it
> >>>>> since
> >>>>>>> my
> >>>>>>>>>> Linux
> >>>>>>>>>>> box is down.
> >>>>>>>>>>> 2. Did you run all tests ( smoke, cuint, kernel, and
> >>>>> classlib )?
> >>>>>>>>> Since
> >>>>>>>>>>> this fully turns on lazy exceptions, we need to ensure that
> >>>>> all
> >>>>>>> tests
> >>>>>>>>>>> pass,
> >>>>>>>>>>> or at least have identical behaviour before and after the
> >>>>> pacth.
> >>>>>>>>>>> 3. Adding a finalizer based stack test to smoke is a good
> >>>>> idea.
> >>>>>>>>>>> 4. On Linux you extend the guard region up ( or down
> >>>>> whatever )
> >>>>>>> by a
> >>>>>>>>>>> page. Did you find a good reason for it, or is this just
> >>>> being
> >>>>>>>>> careful?
> >>>>>>>>>>> Rana
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>> Rana,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Everything is correct in you description, but it looks
> >>>> like
> >>>>> that
> >>>>>>> *
> >>>>>>>>>>>> HARMONY-2018* <
> >>>>>>> https://issues.apache.org/jira/browse/HARMONY-2018>
> >>>>>>>>>>> should
> >>>>>>>>>>>> fix described bug. I think Alexei will have a chance to
> >>>>> check
> >>>>>>> it.
> >>>
> >>>
> >>
> >
>
--
Thank you,
Alexei
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I spoke too soon - do you mean reusing the code for managing the exclude
lists?
geir
Geir Magnusson Jr. wrote:
>
>
> Tim Ellison wrote:
>> Before you go off writing more code, just take a moment to look at
>> HARMONY-263 and tell us what you think of it.
>
> It ties us to JUnit. Doesn't moving the exclude list upwards give us
> more freedom?
>
> geir
>
>>
>> Thanks
>> Tim
>>
>> Alexei Zakharov wrote:
>>> Hi Vladimir,
>>>
>>> It seems everybody likes this approach. In that case, I have another
>>> idea for exclude lists. Can't we go further and extend the current
>>> exclude list functionality a bit more? And forget about TestNG and
>>> friends for a while I mean.
>>>
>>> For example, we can put exclude lists into something like:
>>>
>>> exclude.xml:
>>> ---
>>> <exclude-list>
>>> <!-- exclude only particular tests -->
>>> <class name="org.apache.harmony.luni.test.java.io.MyTest">
>>> <test name="testConstructor11"/>
>>> <test name="testMyMethodObjectObjectString_HY1234"/>
>>> </class>
>>> <!-- exclude all tests -->
>>> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
>>> includeAll="true"/>
>>> ...
>>> </exclude-list>
>>>
>>> exclude.linux.drlvm.xml:
>>> ---
>>> <exclude-list>
>>> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
>>> <test name="testLinuxHang_my"/>
>>> </class>
>>> </exclude-list>
>>>
>>> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
>>> controller test suite by ant. By the controller test suite I mean the
>>> java class that knows how to parse the above files (using simple SAX
>>> parser for example - it is easy, I can help if needed) and implements
>>> junit TestSuite model to get fine-grained control over the testing
>>> process.
>>>
>>> IMHO this can be a nice solution for now. It's more powerful since it
>>> allows to exclude individual tests rather that whole classes. What do
>>> you think?
>>>
>>> Thanks,
>>>
>>>
>>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>>>> Seems, we says about different things :)
>>>>
>>>> First of all, we have no TestNG (or other harness) yet but we need now
>>>> different exclude lists for different platforms.
>>>>
>>>> Also, in my vision these exclude-lists are like a buffer before we
>>>> mark test
>>>> by correct tags.
>>>> When the test fails on some platform we update the corresponding
>>>> x-list and
>>>> investigate this failure.
>>>> As the result of investigation we mark the test or fix it.
>>>>
>>>> Thanks, Vladimir
>>>>
>>>>
>>>> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>>>>> Things become more and more complicated. Can anyone say why we
>>>>> rejected to use TestSuites for this purpose from the very beginning?
>>>>> Well, I can't say I am against using xml lists here. But the next step
>>>>> will be to keep list of individual failing test methods in the xml
>>>>> file. Then to create separate xml lists for api and impl tests and so
>>>>> on. If we can't run original TestNG on Harmony then we invent it by
>>>>> ourselves. :-)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>>>>>> As part of solution for this issue the
>>>>>> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
>>>>>> created.
>>>>>>
>>>>>> I suggest using the separate exclude list for each platform. I
>>>> hope in
>>>>> this
>>>>>> case the test enabling for the different platforms will be easy.
>>>> Please,
>>>>>> look at it.
>>>>>>
>>>>>> Any comments are welcome :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, Vladimir
>>>>>>
>>>>>>
>>>>>> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>>>>>>> Pavel, you are correct. Rana, sorry for confusion. Both issues
>>>> block
>>>>>>> passing class library unit tests.
>>>>>>>
>>>>>>> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>>>>>>> Unhandled exception in java.exe while java.util.jar module tests
>>>>>>> execution
>>>>>>>
>>>>>>> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>>>>>>> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>>>>>>>
>>>>>>> I've used a debugger and caught an assert in
>>>>>>> exn_raise_by_name_internal for the second one. The first one
>>>> contains
>>>>>>> three diffrent issues, and I cannot say where exactly the
>>>> problem is.
>>>>>>> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>>>>>>>> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>>>>>>>>
>>>>>>>> Alexei, is it correct? If not, could you clarify the point about
>>>>>>>> exn_raise_by_name_internal in your initial letter, please?
>>>>>>>>
>>>>>>>>
>>>>>>>> Pavel Afremov.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>>>>>>>>> OK thanks Pavel, I'll try the patch today.
>>>>>>>>>
>>>>>>>>> Rana
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>>>>>>>>>> Hi Rana.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I extend guard region as work around. It's only one way,
>>>> which
>>>>> "fix"
>>>>>>> SOE
>>>>>>>>>> on
>>>>>>>>>> my SuSE Linux, without potential regression of your fix.
>>>> On my
>>>>> Linux
>>>>>>>>>> machine
>>>>>>>>>> violation access signals happen one page before protected
>>>> page
>>>>> on
>>>>>>> the
>>>>>>>>>> stack.
>>>>>>>>>> It's it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I ran all tests, and everything was OK. But strange
>>>> misprint was
>>>>>>> fount
>>>>>>>>> in
>>>>>>>>>> the new test.
>>>>>>>>>>
>>>>>>>>>> So I attach new fixed patch.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Pavel Afremov.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>>>>>>>>>>> Though I tried several times, I could not repro 2070 or
>>>>> Alexey's
>>>>>>>>>> specific
>>>>>>>>>>> problems. The test attached to 2018 repros, and that I
>>>> think
>>>>> is
>>>>>>>>> enough.
>>>>>>>>>>> Pavel,
>>>>>>>>>>> 1. The patch looks good, but I could not apply and try it
>>>>> since
>>>>>>> my
>>>>>>>>>> Linux
>>>>>>>>>>> box is down.
>>>>>>>>>>> 2. Did you run all tests ( smoke, cuint, kernel, and
>>>>> classlib )?
>>>>>>>>> Since
>>>>>>>>>>> this fully turns on lazy exceptions, we need to ensure that
>>>>> all
>>>>>>> tests
>>>>>>>>>>> pass,
>>>>>>>>>>> or at least have identical behaviour before and after the
>>>>> pacth.
>>>>>>>>>>> 3. Adding a finalizer based stack test to smoke is a good
>>>>> idea.
>>>>>>>>>>> 4. On Linux you extend the guard region up ( or down
>>>>> whatever )
>>>>>>> by a
>>>>>>>>>>> page. Did you find a good reason for it, or is this just
>>>> being
>>>>>>>>> careful?
>>>>>>>>>>> Rana
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
>>>> wrote:
>>>>>>>>>>>> Rana,
>>>>>>>>>>>>
>>>>>>>>>>>> Everything is correct in you description, but it looks
>>>> like
>>>>> that
>>>>>>> *
>>>>>>>>>>>> HARMONY-2018* <
>>>>>>> https://issues.apache.org/jira/browse/HARMONY-2018>
>>>>>>>>>>> should
>>>>>>>>>>>> fix described bug. I think Alexei will have a chance to
>>>>> check
>>>>>>> it.
>>>
>>>
>>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Before you go off writing more code, just take a moment to look at
> HARMONY-263 and tell us what you think of it.
It ties us to JUnit. Doesn't moving the exclude list upwards give us
more freedom?
geir
>
> Thanks
> Tim
>
> Alexei Zakharov wrote:
>> Hi Vladimir,
>>
>> It seems everybody likes this approach. In that case, I have another
>> idea for exclude lists. Can't we go further and extend the current
>> exclude list functionality a bit more? And forget about TestNG and
>> friends for a while I mean.
>>
>> For example, we can put exclude lists into something like:
>>
>> exclude.xml:
>> ---
>> <exclude-list>
>> <!-- exclude only particular tests -->
>> <class name="org.apache.harmony.luni.test.java.io.MyTest">
>> <test name="testConstructor11"/>
>> <test name="testMyMethodObjectObjectString_HY1234"/>
>> </class>
>> <!-- exclude all tests -->
>> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
>> includeAll="true"/>
>> ...
>> </exclude-list>
>>
>> exclude.linux.drlvm.xml:
>> ---
>> <exclude-list>
>> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
>> <test name="testLinuxHang_my"/>
>> </class>
>> </exclude-list>
>>
>> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
>> controller test suite by ant. By the controller test suite I mean the
>> java class that knows how to parse the above files (using simple SAX
>> parser for example - it is easy, I can help if needed) and implements
>> junit TestSuite model to get fine-grained control over the testing
>> process.
>>
>> IMHO this can be a nice solution for now. It's more powerful since it
>> allows to exclude individual tests rather that whole classes. What do
>> you think?
>>
>> Thanks,
>>
>>
>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>>> Seems, we says about different things :)
>>>
>>> First of all, we have no TestNG (or other harness) yet but we need now
>>> different exclude lists for different platforms.
>>>
>>> Also, in my vision these exclude-lists are like a buffer before we
>>> mark test
>>> by correct tags.
>>> When the test fails on some platform we update the corresponding
>>> x-list and
>>> investigate this failure.
>>> As the result of investigation we mark the test or fix it.
>>>
>>> Thanks, Vladimir
>>>
>>>
>>> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>>>> Things become more and more complicated. Can anyone say why we
>>>> rejected to use TestSuites for this purpose from the very beginning?
>>>> Well, I can't say I am against using xml lists here. But the next step
>>>> will be to keep list of individual failing test methods in the xml
>>>> file. Then to create separate xml lists for api and impl tests and so
>>>> on. If we can't run original TestNG on Harmony then we invent it by
>>>> ourselves. :-)
>>>>
>>>> Thanks,
>>>>
>>>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>>>>> As part of solution for this issue the
>>>>> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
>>>>> created.
>>>>>
>>>>> I suggest using the separate exclude list for each platform. I
>>> hope in
>>>> this
>>>>> case the test enabling for the different platforms will be easy.
>>> Please,
>>>>> look at it.
>>>>>
>>>>> Any comments are welcome :)
>>>>>
>>>>>
>>>>>
>>>>> Thanks, Vladimir
>>>>>
>>>>>
>>>>> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>>>>>> Pavel, you are correct. Rana, sorry for confusion. Both issues
>>> block
>>>>>> passing class library unit tests.
>>>>>>
>>>>>> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>>>>>> Unhandled exception in java.exe while java.util.jar module tests
>>>>>> execution
>>>>>>
>>>>>> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>>>>>> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>>>>>>
>>>>>> I've used a debugger and caught an assert in
>>>>>> exn_raise_by_name_internal for the second one. The first one
>>> contains
>>>>>> three diffrent issues, and I cannot say where exactly the
>>> problem is.
>>>>>> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>>>>>>> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>>>>>>>
>>>>>>> Alexei, is it correct? If not, could you clarify the point about
>>>>>>> exn_raise_by_name_internal in your initial letter, please?
>>>>>>>
>>>>>>>
>>>>>>> Pavel Afremov.
>>>>>>>
>>>>>>>
>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>>>>>>>> OK thanks Pavel, I'll try the patch today.
>>>>>>>>
>>>>>>>> Rana
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>>>>>>>>> Hi Rana.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I extend guard region as work around. It's only one way,
>>> which
>>>> "fix"
>>>>>> SOE
>>>>>>>>> on
>>>>>>>>> my SuSE Linux, without potential regression of your fix.
>>> On my
>>>> Linux
>>>>>>>>> machine
>>>>>>>>> violation access signals happen one page before protected
>>> page
>>>> on
>>>>>> the
>>>>>>>>> stack.
>>>>>>>>> It's it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I ran all tests, and everything was OK. But strange
>>> misprint was
>>>>>> fount
>>>>>>>> in
>>>>>>>>> the new test.
>>>>>>>>>
>>>>>>>>> So I attach new fixed patch.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pavel Afremov.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>>>>>>>>>> Though I tried several times, I could not repro 2070 or
>>>> Alexey's
>>>>>>>>> specific
>>>>>>>>>> problems. The test attached to 2018 repros, and that I
>>> think
>>>> is
>>>>>>>> enough.
>>>>>>>>>> Pavel,
>>>>>>>>>> 1. The patch looks good, but I could not apply and try it
>>>> since
>>>>>> my
>>>>>>>>> Linux
>>>>>>>>>> box is down.
>>>>>>>>>> 2. Did you run all tests ( smoke, cuint, kernel, and
>>>> classlib )?
>>>>>>>> Since
>>>>>>>>>> this fully turns on lazy exceptions, we need to ensure that
>>>> all
>>>>>> tests
>>>>>>>>>> pass,
>>>>>>>>>> or at least have identical behaviour before and after the
>>>> pacth.
>>>>>>>>>> 3. Adding a finalizer based stack test to smoke is a good
>>>> idea.
>>>>>>>>>> 4. On Linux you extend the guard region up ( or down
>>>> whatever )
>>>>>> by a
>>>>>>>>>> page. Did you find a good reason for it, or is this just
>>> being
>>>>>>>> careful?
>>>>>>>>>> Rana
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
>>> wrote:
>>>>>>>>>>> Rana,
>>>>>>>>>>>
>>>>>>>>>>> Everything is correct in you description, but it looks
>>> like
>>>> that
>>>>>> *
>>>>>>>>>>> HARMONY-2018* <
>>>>>> https://issues.apache.org/jira/browse/HARMONY-2018>
>>>>>>>>>> should
>>>>>>>>>>> fix described bug. I think Alexei will have a chance to
>>>> check
>>>>>> it.
>>
>>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by Tim Ellison <t....@gmail.com>.
Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.
Thanks
Tim
Alexei Zakharov wrote:
> Hi Vladimir,
>
> It seems everybody likes this approach. In that case, I have another
> idea for exclude lists. Can't we go further and extend the current
> exclude list functionality a bit more? And forget about TestNG and
> friends for a while I mean.
>
> For example, we can put exclude lists into something like:
>
> exclude.xml:
> ---
> <exclude-list>
> <!-- exclude only particular tests -->
> <class name="org.apache.harmony.luni.test.java.io.MyTest">
> <test name="testConstructor11"/>
> <test name="testMyMethodObjectObjectString_HY1234"/>
> </class>
> <!-- exclude all tests -->
> <class name="org.apache.harmony.luni.test.java.io.NiceTest2"
> includeAll="true"/>
> ...
> </exclude-list>
>
> exclude.linux.drlvm.xml:
> ---
> <exclude-list>
> <class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
> <test name="testLinuxHang_my"/>
> </class>
> </exclude-list>
>
> And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
> controller test suite by ant. By the controller test suite I mean the
> java class that knows how to parse the above files (using simple SAX
> parser for example - it is easy, I can help if needed) and implements
> junit TestSuite model to get fine-grained control over the testing
> process.
>
> IMHO this can be a nice solution for now. It's more powerful since it
> allows to exclude individual tests rather that whole classes. What do
> you think?
>
> Thanks,
>
>
> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>> Seems, we says about different things :)
>>
>> First of all, we have no TestNG (or other harness) yet but we need now
>> different exclude lists for different platforms.
>>
>> Also, in my vision these exclude-lists are like a buffer before we
>> mark test
>> by correct tags.
>> When the test fails on some platform we update the corresponding
>> x-list and
>> investigate this failure.
>> As the result of investigation we mark the test or fix it.
>>
>> Thanks, Vladimir
>>
>>
>> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>> >
>> > Things become more and more complicated. Can anyone say why we
>> > rejected to use TestSuites for this purpose from the very beginning?
>> > Well, I can't say I am against using xml lists here. But the next step
>> > will be to keep list of individual failing test methods in the xml
>> > file. Then to create separate xml lists for api and impl tests and so
>> > on. If we can't run original TestNG on Harmony then we invent it by
>> > ourselves. :-)
>> >
>> > Thanks,
>> >
>> > 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>> > > As part of solution for this issue the
>> > > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
>> > > created.
>> > >
>> > > I suggest using the separate exclude list for each platform. I
>> hope in
>> > this
>> > > case the test enabling for the different platforms will be easy.
>> Please,
>> > > look at it.
>> > >
>> > > Any comments are welcome :)
>> > >
>> > >
>> > >
>> > > Thanks, Vladimir
>> > >
>> > >
>> > > On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>> > > >
>> > > > Pavel, you are correct. Rana, sorry for confusion. Both issues
>> block
>> > > > passing class library unit tests.
>> > > >
>> > > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>> > > > Unhandled exception in java.exe while java.util.jar module tests
>> > > > execution
>> > > >
>> > > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>> > > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>> > > >
>> > > > I've used a debugger and caught an assert in
>> > > > exn_raise_by_name_internal for the second one. The first one
>> contains
>> > > > three diffrent issues, and I cannot say where exactly the
>> problem is.
>> > > >
>> > > > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> > > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>> > > > >
>> > > > > Alexei, is it correct? If not, could you clarify the point about
>> > > > > exn_raise_by_name_internal in your initial letter, please?
>> > > > >
>> > > > >
>> > > > > Pavel Afremov.
>> > > > >
>> > > > >
>> > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > >
>> > > > > > OK thanks Pavel, I'll try the patch today.
>> > > > > >
>> > > > > > Rana
>> > > > > >
>> > > > > >
>> > > > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>> > > > > > >
>> > > > > > > Hi Rana.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > I extend guard region as work around. It's only one way,
>> which
>> > "fix"
>> > > > SOE
>> > > > > > > on
>> > > > > > > my SuSE Linux, without potential regression of your fix.
>> On my
>> > Linux
>> > > >
>> > > > > > > machine
>> > > > > > > violation access signals happen one page before protected
>> page
>> > on
>> > > > the
>> > > > > > > stack.
>> > > > > > > It's it.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > I ran all tests, and everything was OK. But strange
>> misprint was
>> > > > fount
>> > > > > > in
>> > > > > > > the new test.
>> > > > > > >
>> > > > > > > So I attach new fixed patch.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Pavel Afremov.
>> > > > > > >
>> > > > > > >
>> > > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > > > >
>> > > > > > > > Though I tried several times, I could not repro 2070 or
>> > Alexey's
>> > > > > > > specific
>> > > > > > > > problems. The test attached to 2018 repros, and that I
>> think
>> > is
>> > > > > > enough.
>> > > > > > > >
>> > > > > > > > Pavel,
>> > > > > > > > 1. The patch looks good, but I could not apply and try it
>> > since
>> > > > my
>> > > > > > > Linux
>> > > > > > > > box is down.
>> > > > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
>> > classlib )?
>> > > >
>> > > > > > Since
>> > > > > > > > this fully turns on lazy exceptions, we need to ensure that
>> > all
>> > > > tests
>> > > > > > > > pass,
>> > > > > > > > or at least have identical behaviour before and after the
>> > pacth.
>> > > > > > > > 3. Adding a finalizer based stack test to smoke is a good
>> > idea.
>> > > > > > > > 4. On Linux you extend the guard region up ( or down
>> > whatever )
>> > > > by a
>> > > > > > > > page. Did you find a good reason for it, or is this just
>> being
>> > > > > > careful?
>> > > > > > > >
>> > > > > > > > Rana
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com>
>> wrote:
>> > > > > > > > >
>> > > > > > > > > Rana,
>> > > > > > > > >
>> > > > > > > > > Everything is correct in you description, but it looks
>> like
>> > that
>> > > > *
>> > > > > > > > > HARMONY-2018* <
>> > > > https://issues.apache.org/jira/browse/HARMONY-2018>
>> > > > > > > > should
>> > > > > > > > > fix described bug. I think Alexei will have a chance to
>> > check
>> > > > it.
>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Vladimir,
It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.
For example, we can put exclude lists into something like:
exclude.xml:
---
<exclude-list>
<!-- exclude only particular tests -->
<class name="org.apache.harmony.luni.test.java.io.MyTest">
<test name="testConstructor11"/>
<test name="testMyMethodObjectObjectString_HY1234"/>
</class>
<!-- exclude all tests -->
<class name="org.apache.harmony.luni.test.java.io.NiceTest2"
includeAll="true"/>
...
</exclude-list>
exclude.linux.drlvm.xml:
---
<exclude-list>
<class name="org.apache.harmony.rmi.test.java.rmi.ВadBoyTest">
<test name="testLinuxHang_my"/>
</class>
</exclude-list>
And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.
IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?
Thanks,
2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> Seems, we says about different things :)
>
> First of all, we have no TestNG (or other harness) yet but we need now
> different exclude lists for different platforms.
>
> Also, in my vision these exclude-lists are like a buffer before we mark test
> by correct tags.
> When the test fails on some platform we update the corresponding x-list and
> investigate this failure.
> As the result of investigation we mark the test or fix it.
>
> Thanks, Vladimir
>
>
> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
> >
> > Things become more and more complicated. Can anyone say why we
> > rejected to use TestSuites for this purpose from the very beginning?
> > Well, I can't say I am against using xml lists here. But the next step
> > will be to keep list of individual failing test methods in the xml
> > file. Then to create separate xml lists for api and impl tests and so
> > on. If we can't run original TestNG on Harmony then we invent it by
> > ourselves. :-)
> >
> > Thanks,
> >
> > 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> > > As part of solution for this issue the
> > > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> > > created.
> > >
> > > I suggest using the separate exclude list for each platform. I hope in
> > this
> > > case the test enabling for the different platforms will be easy. Please,
> > > look at it.
> > >
> > > Any comments are welcome :)
> > >
> > >
> > >
> > > Thanks, Vladimir
> > >
> > >
> > > On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
> > > >
> > > > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > > > passing class library unit tests.
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > > Unhandled exception in java.exe while java.util.jar module tests
> > > > execution
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > > >
> > > > I've used a debugger and caught an assert in
> > > > exn_raise_by_name_internal for the second one. The first one contains
> > > > three diffrent issues, and I cannot say where exactly the problem is.
> > > >
> > > > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > > >
> > > > > Alexei, is it correct? If not, could you clarify the point about
> > > > > exn_raise_by_name_internal in your initial letter, please?
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > >
> > > > > > OK thanks Pavel, I'll try the patch today.
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Rana.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I extend guard region as work around. It's only one way, which
> > "fix"
> > > > SOE
> > > > > > > on
> > > > > > > my SuSE Linux, without potential regression of your fix. On my
> > Linux
> > > >
> > > > > > > machine
> > > > > > > violation access signals happen one page before protected page
> > on
> > > > the
> > > > > > > stack.
> > > > > > > It's it.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I ran all tests, and everything was OK. But strange misprint was
> > > > fount
> > > > > > in
> > > > > > > the new test.
> > > > > > >
> > > > > > > So I attach new fixed patch.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Pavel Afremov.
> > > > > > >
> > > > > > >
> > > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Though I tried several times, I could not repro 2070 or
> > Alexey's
> > > > > > > specific
> > > > > > > > problems. The test attached to 2018 repros, and that I think
> > is
> > > > > > enough.
> > > > > > > >
> > > > > > > > Pavel,
> > > > > > > > 1. The patch looks good, but I could not apply and try it
> > since
> > > > my
> > > > > > > Linux
> > > > > > > > box is down.
> > > > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
> > classlib )?
> > > >
> > > > > > Since
> > > > > > > > this fully turns on lazy exceptions, we need to ensure that
> > all
> > > > tests
> > > > > > > > pass,
> > > > > > > > or at least have identical behaviour before and after the
> > pacth.
> > > > > > > > 3. Adding a finalizer based stack test to smoke is a good
> > idea.
> > > > > > > > 4. On Linux you extend the guard region up ( or down
> > whatever )
> > > > by a
> > > > > > > > page. Did you find a good reason for it, or is this just being
> > > > > > careful?
> > > > > > > >
> > > > > > > > Rana
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Rana,
> > > > > > > > >
> > > > > > > > > Everything is correct in you description, but it looks like
> > that
> > > > *
> > > > > > > > > HARMONY-2018* <
> > > > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > > > should
> > > > > > > > > fix described bug. I think Alexei will have a chance to
> > check
> > > > it.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [drlvm] [testing] Excluding commit tests until the problem is
fixed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
We should also take a hard look at how to do this in DRLVM as well...
Vladimir Ivanov wrote:
> Seems, we says about different things :)
>
> First of all, we have no TestNG (or other harness) yet but we need now
> different exclude lists for different platforms.
>
> Also, in my vision these exclude-lists are like a buffer before we mark
> test
> by correct tags.
> When the test fails on some platform we update the corresponding x-list and
> investigate this failure.
> As the result of investigation we mark the test or fix it.
>
> Thanks, Vladimir
>
>
> On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>>
>> Things become more and more complicated. Can anyone say why we
>> rejected to use TestSuites for this purpose from the very beginning?
>> Well, I can't say I am against using xml lists here. But the next step
>> will be to keep list of individual failing test methods in the xml
>> file. Then to create separate xml lists for api and impl tests and so
>> on. If we can't run original TestNG on Harmony then we invent it by
>> ourselves. :-)
>>
>> Thanks,
>>
>> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
>> > As part of solution for this issue the
>> > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
>> > created.
>> >
>> > I suggest using the separate exclude list for each platform. I hope in
>> this
>> > case the test enabling for the different platforms will be easy.
>> Please,
>> > look at it.
>> >
>> > Any comments are welcome :)
>> >
>> >
>> >
>> > Thanks, Vladimir
>> >
>> >
>> > On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>> > >
>> > > Pavel, you are correct. Rana, sorry for confusion. Both issues block
>> > > passing class library unit tests.
>> > >
>> > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
>> > > Unhandled exception in java.exe while java.util.jar module tests
>> > > execution
>> > >
>> > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
>> > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>> > >
>> > > I've used a debugger and caught an assert in
>> > > exn_raise_by_name_internal for the second one. The first one contains
>> > > three diffrent issues, and I cannot say where exactly the problem is.
>> > >
>> > > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>> > > >
>> > > > Alexei, is it correct? If not, could you clarify the point about
>> > > > exn_raise_by_name_internal in your initial letter, please?
>> > > >
>> > > >
>> > > > Pavel Afremov.
>> > > >
>> > > >
>> > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > >
>> > > > > OK thanks Pavel, I'll try the patch today.
>> > > > >
>> > > > > Rana
>> > > > >
>> > > > >
>> > > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>> > > > > >
>> > > > > > Hi Rana.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > I extend guard region as work around. It's only one way, which
>> "fix"
>> > > SOE
>> > > > > > on
>> > > > > > my SuSE Linux, without potential regression of your fix. On my
>> Linux
>> > >
>> > > > > > machine
>> > > > > > violation access signals happen one page before protected page
>> on
>> > > the
>> > > > > > stack.
>> > > > > > It's it.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > I ran all tests, and everything was OK. But strange misprint
>> was
>> > > fount
>> > > > > in
>> > > > > > the new test.
>> > > > > >
>> > > > > > So I attach new fixed patch.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Pavel Afremov.
>> > > > > >
>> > > > > >
>> > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > > >
>> > > > > > > Though I tried several times, I could not repro 2070 or
>> Alexey's
>> > > > > > specific
>> > > > > > > problems. The test attached to 2018 repros, and that I think
>> is
>> > > > > enough.
>> > > > > > >
>> > > > > > > Pavel,
>> > > > > > > 1. The patch looks good, but I could not apply and try it
>> since
>> > > my
>> > > > > > Linux
>> > > > > > > box is down.
>> > > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
>> classlib )?
>> > >
>> > > > > Since
>> > > > > > > this fully turns on lazy exceptions, we need to ensure that
>> all
>> > > tests
>> > > > > > > pass,
>> > > > > > > or at least have identical behaviour before and after the
>> pacth.
>> > > > > > > 3. Adding a finalizer based stack test to smoke is a good
>> idea.
>> > > > > > > 4. On Linux you extend the guard region up ( or down
>> whatever )
>> > > by a
>> > > > > > > page. Did you find a good reason for it, or is this just
>> being
>> > > > > careful?
>> > > > > > >
>> > > > > > > Rana
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
>> > > > > > > >
>> > > > > > > > Rana,
>> > > > > > > >
>> > > > > > > > Everything is correct in you description, but it looks like
>> that
>> > > *
>> > > > > > > > HARMONY-2018* <
>> > > https://issues.apache.org/jira/browse/HARMONY-2018>
>> > > > > > > should
>> > > > > > > > fix described bug. I think Alexei will have a chance to
>> check
>> > > it.
>>
>> --
>> Alexei Zakharov,
>> Intel Enterprise Solutions Software Division
>>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Vladimir Ivanov <iv...@gmail.com>.
Seems, we says about different things :)
First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.
Also, in my vision these exclude-lists are like a buffer before we mark test
by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.
Thanks, Vladimir
On 11/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>
> Things become more and more complicated. Can anyone say why we
> rejected to use TestSuites for this purpose from the very beginning?
> Well, I can't say I am against using xml lists here. But the next step
> will be to keep list of individual failing test methods in the xml
> file. Then to create separate xml lists for api and impl tests and so
> on. If we can't run original TestNG on Harmony then we invent it by
> ourselves. :-)
>
> Thanks,
>
> 2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> > As part of solution for this issue the
> > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> > created.
> >
> > I suggest using the separate exclude list for each platform. I hope in
> this
> > case the test enabling for the different platforms will be easy. Please,
> > look at it.
> >
> > Any comments are welcome :)
> >
> >
> >
> > Thanks, Vladimir
> >
> >
> > On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
> > >
> > > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > > passing class library unit tests.
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > Unhandled exception in java.exe while java.util.jar module tests
> > > execution
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > >
> > > I've used a debugger and caught an assert in
> > > exn_raise_by_name_internal for the second one. The first one contains
> > > three diffrent issues, and I cannot say where exactly the problem is.
> > >
> > > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > >
> > > > Alexei, is it correct? If not, could you clarify the point about
> > > > exn_raise_by_name_internal in your initial letter, please?
> > > >
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > >
> > > > > OK thanks Pavel, I'll try the patch today.
> > > > >
> > > > > Rana
> > > > >
> > > > >
> > > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > > > >
> > > > > > Hi Rana.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I extend guard region as work around. It's only one way, which
> "fix"
> > > SOE
> > > > > > on
> > > > > > my SuSE Linux, without potential regression of your fix. On my
> Linux
> > >
> > > > > > machine
> > > > > > violation access signals happen one page before protected page
> on
> > > the
> > > > > > stack.
> > > > > > It's it.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I ran all tests, and everything was OK. But strange misprint was
> > > fount
> > > > > in
> > > > > > the new test.
> > > > > >
> > > > > > So I attach new fixed patch.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pavel Afremov.
> > > > > >
> > > > > >
> > > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > >
> > > > > > > Though I tried several times, I could not repro 2070 or
> Alexey's
> > > > > > specific
> > > > > > > problems. The test attached to 2018 repros, and that I think
> is
> > > > > enough.
> > > > > > >
> > > > > > > Pavel,
> > > > > > > 1. The patch looks good, but I could not apply and try it
> since
> > > my
> > > > > > Linux
> > > > > > > box is down.
> > > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and
> classlib )?
> > >
> > > > > Since
> > > > > > > this fully turns on lazy exceptions, we need to ensure that
> all
> > > tests
> > > > > > > pass,
> > > > > > > or at least have identical behaviour before and after the
> pacth.
> > > > > > > 3. Adding a finalizer based stack test to smoke is a good
> idea.
> > > > > > > 4. On Linux you extend the guard region up ( or down
> whatever )
> > > by a
> > > > > > > page. Did you find a good reason for it, or is this just being
> > > > > careful?
> > > > > > >
> > > > > > > Rana
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Rana,
> > > > > > > >
> > > > > > > > Everything is correct in you description, but it looks like
> that
> > > *
> > > > > > > > HARMONY-2018* <
> > > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > > should
> > > > > > > > fix described bug. I think Alexei will have a chance to
> check
> > > it.
>
> --
> Alexei Zakharov,
> Intel Enterprise Solutions Software Division
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Alexei Zakharov <al...@gmail.com>.
Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)
Thanks,
2006/11/15, Vladimir Ivanov <iv...@gmail.com>:
> As part of solution for this issue the
> *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)
>
>
>
> Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
> >
> > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > passing class library unit tests.
> >
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > Unhandled exception in java.exe while java.util.jar module tests
> > execution
> >
> > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >
> > I've used a debugger and caught an assert in
> > exn_raise_by_name_internal for the second one. The first one contains
> > three diffrent issues, and I cannot say where exactly the problem is.
> >
> > On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > >
> > > Alexei, is it correct? If not, could you clarify the point about
> > > exn_raise_by_name_internal in your initial letter, please?
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > >
> > > > OK thanks Pavel, I'll try the patch today.
> > > >
> > > > Rana
> > > >
> > > >
> > > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > > >
> > > > > Hi Rana.
> > > > >
> > > > >
> > > > >
> > > > > I extend guard region as work around. It's only one way, which "fix"
> > SOE
> > > > > on
> > > > > my SuSE Linux, without potential regression of your fix. On my Linux
> >
> > > > > machine
> > > > > violation access signals happen one page before protected page on
> > the
> > > > > stack.
> > > > > It's it.
> > > > >
> > > > >
> > > > >
> > > > > I ran all tests, and everything was OK. But strange misprint was
> > fount
> > > > in
> > > > > the new test.
> > > > >
> > > > > So I attach new fixed patch.
> > > > >
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > >
> > > > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > > > specific
> > > > > > problems. The test attached to 2018 repros, and that I think is
> > > > enough.
> > > > > >
> > > > > > Pavel,
> > > > > > 1. The patch looks good, but I could not apply and try it since
> > my
> > > > > Linux
> > > > > > box is down.
> > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
> >
> > > > Since
> > > > > > this fully turns on lazy exceptions, we need to ensure that all
> > tests
> > > > > > pass,
> > > > > > or at least have identical behaviour before and after the pacth.
> > > > > > 3. Adding a finalizer based stack test to smoke is a good idea.
> > > > > > 4. On Linux you extend the guard region up ( or down whatever )
> > by a
> > > > > > page. Did you find a good reason for it, or is this just being
> > > > careful?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > > >
> > > > > > > Rana,
> > > > > > >
> > > > > > > Everything is correct in you description, but it looks like that
> > *
> > > > > > > HARMONY-2018* <
> > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > should
> > > > > > > fix described bug. I think Alexei will have a chance to check
> > it.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Vladimir Ivanov <iv...@gmail.com>.
As part of solution for this issue the
*HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
created.
I suggest using the separate exclude list for each platform. I hope in this
case the test enabling for the different platforms will be easy. Please,
look at it.
Any comments are welcome :)
Thanks, Vladimir
On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>
> Pavel, you are correct. Rana, sorry for confusion. Both issues block
> passing class library unit tests.
>
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> Unhandled exception in java.exe while java.util.jar module tests
> execution
>
> http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
>
> I've used a debugger and caught an assert in
> exn_raise_by_name_internal for the second one. The first one contains
> three diffrent issues, and I cannot say where exactly the problem is.
>
> On 11/15/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> >
> > Alexei, is it correct? If not, could you clarify the point about
> > exn_raise_by_name_internal in your initial letter, please?
> >
> >
> > Pavel Afremov.
> >
> >
> > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > OK thanks Pavel, I'll try the patch today.
> > >
> > > Rana
> > >
> > >
> > > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > >
> > > > Hi Rana.
> > > >
> > > >
> > > >
> > > > I extend guard region as work around. It's only one way, which "fix"
> SOE
> > > > on
> > > > my SuSE Linux, without potential regression of your fix. On my Linux
>
> > > > machine
> > > > violation access signals happen one page before protected page on
> the
> > > > stack.
> > > > It's it.
> > > >
> > > >
> > > >
> > > > I ran all tests, and everything was OK. But strange misprint was
> fount
> > > in
> > > > the new test.
> > > >
> > > > So I attach new fixed patch.
> > > >
> > > >
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > >
> > > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > > specific
> > > > > problems. The test attached to 2018 repros, and that I think is
> > > enough.
> > > > >
> > > > > Pavel,
> > > > > 1. The patch looks good, but I could not apply and try it since
> my
> > > > Linux
> > > > > box is down.
> > > > > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
>
> > > Since
> > > > > this fully turns on lazy exceptions, we need to ensure that all
> tests
> > > > > pass,
> > > > > or at least have identical behaviour before and after the pacth.
> > > > > 3. Adding a finalizer based stack test to smoke is a good idea.
> > > > > 4. On Linux you extend the guard region up ( or down whatever )
> by a
> > > > > page. Did you find a good reason for it, or is this just being
> > > careful?
> > > > >
> > > > > Rana
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/7/06, Pavel Afremov < pavel.n.afremov@gmail.com> wrote:
> > > > > >
> > > > > > Rana,
> > > > > >
> > > > > > Everything is correct in you description, but it looks like that
> *
> > > > > > HARMONY-2018* <
> https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > should
> > > > > > fix described bug. I think Alexei will have a chance to check
> it.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Pavel Afremov.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
> Thank you,
> Alexei
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Alexei Fedotov <al...@gmail.com>.
Pavel, you are correct. Rana, sorry for confusion. Both issues block
passing class library unit tests.
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution
http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one contains
three diffrent issues, and I cannot say where exactly the problem is.
On 11/15/06, Pavel Afremov <pa...@gmail.com> wrote:
> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>
> Alexei, is it correct? If not, could you clarify the point about
> exn_raise_by_name_internal in your initial letter, please?
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > OK thanks Pavel, I'll try the patch today.
> >
> > Rana
> >
> >
> > On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> > >
> > > Hi Rana.
> > >
> > >
> > >
> > > I extend guard region as work around. It's only one way, which "fix" SOE
> > > on
> > > my SuSE Linux, without potential regression of your fix. On my Linux
> > > machine
> > > violation access signals happen one page before protected page on the
> > > stack.
> > > It's it.
> > >
> > >
> > >
> > > I ran all tests, and everything was OK. But strange misprint was fount
> > in
> > > the new test.
> > >
> > > So I attach new fixed patch.
> > >
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > > >
> > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > specific
> > > > problems. The test attached to 2018 repros, and that I think is
> > enough.
> > > >
> > > > Pavel,
> > > > 1. The patch looks good, but I could not apply and try it since my
> > > Linux
> > > > box is down.
> > > > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
> > Since
> > > > this fully turns on lazy exceptions, we need to ensure that all tests
> > > > pass,
> > > > or at least have identical behaviour before and after the pacth.
> > > > 3. Adding a finalizer based stack test to smoke is a good idea.
> > > > 4. On Linux you extend the guard region up ( or down whatever ) by a
> > > > page. Did you find a good reason for it, or is this just being
> > careful?
> > > >
> > > > Rana
> > > >
> > > >
> > > >
> > > >
> > > > On 11/7/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > > >
> > > > > Rana,
> > > > >
> > > > > Everything is correct in you description, but it looks like that *
> > > > > HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > should
> > > > > fix described bug. I think Alexei will have a chance to check it.
> > > > >
> > > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
--
Thank you,
Alexei
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Pavel Afremov <pa...@gmail.com>.
As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?
Pavel Afremov.
On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
> OK thanks Pavel, I'll try the patch today.
>
> Rana
>
>
> On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
> >
> > Hi Rana.
> >
> >
> >
> > I extend guard region as work around. It's only one way, which "fix" SOE
> > on
> > my SuSE Linux, without potential regression of your fix. On my Linux
> > machine
> > violation access signals happen one page before protected page on the
> > stack.
> > It's it.
> >
> >
> >
> > I ran all tests, and everything was OK. But strange misprint was fount
> in
> > the new test.
> >
> > So I attach new fixed patch.
> >
> >
> >
> > Pavel Afremov.
> >
> >
> > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > Though I tried several times, I could not repro 2070 or Alexey's
> > specific
> > > problems. The test attached to 2018 repros, and that I think is
> enough.
> > >
> > > Pavel,
> > > 1. The patch looks good, but I could not apply and try it since my
> > Linux
> > > box is down.
> > > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )?
> Since
> > > this fully turns on lazy exceptions, we need to ensure that all tests
> > > pass,
> > > or at least have identical behaviour before and after the pacth.
> > > 3. Adding a finalizer based stack test to smoke is a good idea.
> > > 4. On Linux you extend the guard region up ( or down whatever ) by a
> > > page. Did you find a good reason for it, or is this just being
> careful?
> > >
> > > Rana
> > >
> > >
> > >
> > >
> > > On 11/7/06, Pavel Afremov <pa...@gmail.com> wrote:
> > > >
> > > > Rana,
> > > >
> > > > Everything is correct in you description, but it looks like that *
> > > > HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018>
> > > should
> > > > fix described bug. I think Alexei will have a chance to check it.
> > > >
> > > >
> > > >
> > > > Thank you.
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Rana Dasgupta <rd...@gmail.com>.
OK thanks Pavel, I'll try the patch today.
Rana
On 11/8/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> Hi Rana.
>
>
>
> I extend guard region as work around. It's only one way, which "fix" SOE
> on
> my SuSE Linux, without potential regression of your fix. On my Linux
> machine
> violation access signals happen one page before protected page on the
> stack.
> It's it.
>
>
>
> I ran all tests, and everything was OK. But strange misprint was fount in
> the new test.
>
> So I attach new fixed patch.
>
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > Though I tried several times, I could not repro 2070 or Alexey's
> specific
> > problems. The test attached to 2018 repros, and that I think is enough.
> >
> > Pavel,
> > 1. The patch looks good, but I could not apply and try it since my
> Linux
> > box is down.
> > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
> > this fully turns on lazy exceptions, we need to ensure that all tests
> > pass,
> > or at least have identical behaviour before and after the pacth.
> > 3. Adding a finalizer based stack test to smoke is a good idea.
> > 4. On Linux you extend the guard region up ( or down whatever ) by a
> > page. Did you find a good reason for it, or is this just being careful?
> >
> > Rana
> >
> >
> >
> >
> > On 11/7/06, Pavel Afremov <pa...@gmail.com> wrote:
> > >
> > > Rana,
> > >
> > > Everything is correct in you description, but it looks like that *
> > > HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018>
> > should
> > > fix described bug. I think Alexei will have a chance to check it.
> > >
> > >
> > >
> > > Thank you.
> > >
> > > Pavel Afremov.
> > >
> > >
> > >
> >
> >
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Pavel Afremov <pa...@gmail.com>.
Hi Rana.
I extend guard region as work around. It's only one way, which "fix" SOE on
my SuSE Linux, without potential regression of your fix. On my Linux machine
violation access signals happen one page before protected page on the stack.
It's it.
I ran all tests, and everything was OK. But strange misprint was fount in
the new test.
So I attach new fixed patch.
Pavel Afremov.
On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
> Though I tried several times, I could not repro 2070 or Alexey's specific
> problems. The test attached to 2018 repros, and that I think is enough.
>
> Pavel,
> 1. The patch looks good, but I could not apply and try it since my Linux
> box is down.
> 2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
> this fully turns on lazy exceptions, we need to ensure that all tests
> pass,
> or at least have identical behaviour before and after the pacth.
> 3. Adding a finalizer based stack test to smoke is a good idea.
> 4. On Linux you extend the guard region up ( or down whatever ) by a
> page. Did you find a good reason for it, or is this just being careful?
>
> Rana
>
>
>
>
> On 11/7/06, Pavel Afremov <pa...@gmail.com> wrote:
> >
> > Rana,
> >
> > Everything is correct in you description, but it looks like that *
> > HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018>
> should
> > fix described bug. I think Alexei will have a chance to check it.
> >
> >
> >
> > Thank you.
> >
> > Pavel Afremov.
> >
> >
> >
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Rana Dasgupta <rd...@gmail.com>.
Though I tried several times, I could not repro 2070 or Alexey's specific
problems. The test attached to 2018 repros, and that I think is enough.
Pavel,
1. The patch looks good, but I could not apply and try it since my Linux
box is down.
2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
this fully turns on lazy exceptions, we need to ensure that all tests pass,
or at least have identical behaviour before and after the pacth.
3. Adding a finalizer based stack test to smoke is a good idea.
4. On Linux you extend the guard region up ( or down whatever ) by a
page. Did you find a good reason for it, or is this just being careful?
Rana
On 11/7/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> Rana,
>
> Everything is correct in you description, but it looks like that *
> HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018> should
> fix described bug. I think Alexei will have a chance to check it.
>
>
>
> Thank you.
>
> Pavel Afremov.
>
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Pavel Afremov <pa...@gmail.com>.
Rana,
Everything is correct in you description, but it looks like that *
HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018> should
fix described bug. I think Alexei will have a chance to check it.
Thank you.
Pavel Afremov.
On 11/6/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
> Alexei,
> The1363 submission added functionality for lazy exception support, for
> exceptions in the VM code. exn_raise_by_name_internal was such a function.
> This may not be bug free ( as is true of any code ) and we need to check
> out
> 2070. I will take a look, as should Pavel.
> I think that while committing 1363, StackTest failed and there were
> other
> asserts, which Geir disabled to not block the large submission. This is
> not
> really anything to do with lazy exceptions. This is an issue where parts
> of
> the main thread's stack virtual memory are unmapped on Linux. I later
> added
> a fix for this. The two issues are orthogonal to each other.
>
> Rana
>
>
>
> On 11/5/06, Fedotov, Alexei A <al...@intel.com> wrote:
> >
> > Rana, Pavel (Afremov), All,
> >
> > Geir's comment on r443504 (fix for
> > http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> > bit support, JVMTI improvements) reads:
> >
> > > 1) Stack overflow exception stuff is broken. I had to remove the
> > assert
> > > in signals_ia32.cpp line 336. Rana knows and will look. I also
> > > disabled the StackTest.
> >
> > I have noticed that the patch added a new function
> > exn_raise_by_name_internal which fails on the first invocation checking
> > an assertion about thread state, see
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > crashes DRLVM.
> >
> > I also have noticed that this function is called to create
> > java.lang.StackOverflowError.
> >
> > Could you help me to understand the current status of the problem?
> >
> > With best regards,
> > Alexei Fedotov,
> > Intel Java & XML Engineering
> >
> > >-----Original Message-----
> > >From: Rana Dasgupta [mailto:rdasgupt@gmail.com]
> > >Sent: Wednesday, October 18, 2006 4:27 AM
> > >To: harmony-dev@incubator.apache.org
> > >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> > is
> > >fixed
> > >
> > >I fixed the StackOverflow functionality problem by going back and
> > mapping
> > >all pages ( guard, alternate stack ) meticulously before trying to
> > protect
> > >them. I think we should have done this in the first place. I also
> > cleaned
> > >up the previous initialization workarounds and asserts Geir and I had
> > >discussed on the JIRA. The Stacktest and all other stack related tests
> > now
> > >pass.
> > >
> > >I'll submit the patch against 1786 in the next few hours after running
> > >acceptance tests.
> > >
> > >Rana
> > >
> > >
> > >
> > >> On 10/16/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On 10/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > >> > >
> > >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> > >> > > >> I tried to put some back. StackTest still doesn't work. It's
> > >hard
> > >> > > to
> > >> > > >> believe... so I gave up and just kept going :)
> > >> > >
> > >> > > >I wonder if the test or the implementation are wrong. Maybe
> > someone
> > >> > > who added
> > >> > > >the test initially could know the answer.
> > >> >
> > >> >
> > >> >
> > >> > There is nothing wrong with the stacktest test itself. The
> > >> > > implementation is not quite 100%complete( I think ), but has
> > enough
> > >> > > functionality and the test passes on Windows. On Linux, it fails.
> > I
> > >am not
> > >> > > sure if this is a regression, or if this ever worked. There is a
> > JIRA
> > >issue
> > >> > > 1786. In summary, memory protection setup for the guard page
> > fails on
> > >the
> > >> > > main thread(only). So the guard does not work and the overflow is
> > not
> > >> > > detected.
> > >> >
> > >> >
> > >> > mprotect fails with an ENOMEM which is either a mapping failure
> > or a
> > >> > kernel failure. mprotect() has some known flakiness it seems, as
> > per
> > >> > literature.
> > >> >
> > >> > The basic implementation on Linux is sound. There are secondary
> > >design
> > >> > issues,but we can only get to them later after we have figured out
> > why
> > >the
> > >> > guard setup fails on the main thread.
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> >
>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Rana Dasgupta <rd...@gmail.com>.
Alexei,
The1363 submission added functionality for lazy exception support, for
exceptions in the VM code. exn_raise_by_name_internal was such a function.
This may not be bug free ( as is true of any code ) and we need to check out
2070. I will take a look, as should Pavel.
I think that while committing 1363, StackTest failed and there were other
asserts, which Geir disabled to not block the large submission. This is not
really anything to do with lazy exceptions. This is an issue where parts of
the main thread's stack virtual memory are unmapped on Linux. I later added
a fix for this. The two issues are orthogonal to each other.
Rana
On 11/5/06, Fedotov, Alexei A <al...@intel.com> wrote:
>
> Rana, Pavel (Afremov), All,
>
> Geir's comment on r443504 (fix for
> http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> bit support, JVMTI improvements) reads:
>
> > 1) Stack overflow exception stuff is broken. I had to remove the
> assert
> > in signals_ia32.cpp line 336. Rana knows and will look. I also
> > disabled the StackTest.
>
> I have noticed that the patch added a new function
> exn_raise_by_name_internal which fails on the first invocation checking
> an assertion about thread state, see
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> crashes DRLVM.
>
> I also have noticed that this function is called to create
> java.lang.StackOverflowError.
>
> Could you help me to understand the current status of the problem?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-----Original Message-----
> >From: Rana Dasgupta [mailto:rdasgupt@gmail.com]
> >Sent: Wednesday, October 18, 2006 4:27 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
> >fixed
> >
> >I fixed the StackOverflow functionality problem by going back and
> mapping
> >all pages ( guard, alternate stack ) meticulously before trying to
> protect
> >them. I think we should have done this in the first place. I also
> cleaned
> >up the previous initialization workarounds and asserts Geir and I had
> >discussed on the JIRA. The Stacktest and all other stack related tests
> now
> >pass.
> >
> >I'll submit the patch against 1786 in the next few hours after running
> >acceptance tests.
> >
> >Rana
> >
> >
> >
> >> On 10/16/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On 10/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >> > >
> >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> >> > > >> I tried to put some back. StackTest still doesn't work. It's
> >hard
> >> > > to
> >> > > >> believe... so I gave up and just kept going :)
> >> > >
> >> > > >I wonder if the test or the implementation are wrong. Maybe
> someone
> >> > > who added
> >> > > >the test initially could know the answer.
> >> >
> >> >
> >> >
> >> > There is nothing wrong with the stacktest test itself. The
> >> > > implementation is not quite 100%complete( I think ), but has
> enough
> >> > > functionality and the test passes on Windows. On Linux, it fails.
> I
> >am not
> >> > > sure if this is a regression, or if this ever worked. There is a
> JIRA
> >issue
> >> > > 1786. In summary, memory protection setup for the guard page
> fails on
> >the
> >> > > main thread(only). So the guard does not work and the overflow is
> not
> >> > > detected.
> >> >
> >> >
> >> > mprotect fails with an ENOMEM which is either a mapping failure
> or a
> >> > kernel failure. mprotect() has some known flakiness it seems, as
> per
> >> > literature.
> >> >
> >> > The basic implementation on Linux is sound. There are secondary
> >design
> >> > issues,but we can only get to them later after we have figured out
> why
> >the
> >> > guard setup fails on the main thread.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >>
> >>
> >>
> >>
> >>
>
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Posted by Pavel Afremov <pa...@gmail.com>.
Hello.
Could you be so kind to check
*HARMONY-2018*<https://issues.apache.org/jira/browse/HARMONY-2018>
before start fixing and discussing this bug, please?
I reported it and provided a fix a week ago.
Thanks.
Pavel Afremov.
On 11/5/06, Fedotov, Alexei A <al...@intel.com> wrote:
>
> Rana, Pavel (Afremov), All,
>
> Geir's comment on r443504 (fix for
> http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> bit support, JVMTI improvements) reads:
>
> > 1) Stack overflow exception stuff is broken. I had to remove the
> assert
> > in signals_ia32.cpp line 336. Rana knows and will look. I also
> > disabled the StackTest.
>
> I have noticed that the patch added a new function
> exn_raise_by_name_internal which fails on the first invocation checking
> an assertion about thread state, see
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> crashes DRLVM.
>
> I also have noticed that this function is called to create
> java.lang.StackOverflowError.
>
> Could you help me to understand the current status of the problem?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-----Original Message-----
> >From: Rana Dasgupta [mailto:rdasgupt@gmail.com]
> >Sent: Wednesday, October 18, 2006 4:27 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
> >fixed
> >
> >I fixed the StackOverflow functionality problem by going back and
> mapping
> >all pages ( guard, alternate stack ) meticulously before trying to
> protect
> >them. I think we should have done this in the first place. I also
> cleaned
> >up the previous initialization workarounds and asserts Geir and I had
> >discussed on the JIRA. The Stacktest and all other stack related tests
> now
> >pass.
> >
> >I'll submit the patch against 1786 in the next few hours after running
> >acceptance tests.
> >
> >Rana
> >
> >
> >
> >> On 10/16/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On 10/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >> > >
> >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> >> > > >> I tried to put some back. StackTest still doesn't work. It's
> >hard
> >> > > to
> >> > > >> believe... so I gave up and just kept going :)
> >> > >
> >> > > >I wonder if the test or the implementation are wrong. Maybe
> someone
> >> > > who added
> >> > > >the test initially could know the answer.
> >> >
> >> >
> >> >
> >> > There is nothing wrong with the stacktest test itself. The
> >> > > implementation is not quite 100%complete( I think ), but has
> enough
> >> > > functionality and the test passes on Windows. On Linux, it fails.
> I
> >am not
> >> > > sure if this is a regression, or if this ever worked. There is a
> JIRA
> >issue
> >> > > 1786. In summary, memory protection setup for the guard page
> fails on
> >the
> >> > > main thread(only). So the guard does not work and the overflow is
> not
> >> > > detected.
> >> >
> >> >
> >> > mprotect fails with an ENOMEM which is either a mapping failure
> or a
> >> > kernel failure. mprotect() has some known flakiness it seems, as
> per
> >> > literature.
> >> >
> >> > The basic implementation on Linux is sound. There are secondary
> >design
> >> > issues,but we can only get to them later after we have figured out
> why
> >the
> >> > guard setup fails on the main thread.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >>
> >>
> >>
> >>
> >>
>