harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general][testing] need a piece of advise: how we can handle VM crashes
Date Fri, 08 Dec 2006 01:54:57 GMT
Alexander,
Thank you for answers and encouragement!

On 12/7/06, Alexander Kleymenov <kleymenov@gmail.com> wrote:
> Hi Alexei,
>
> On 12/7/06, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > Alexander,
> >
> > It is great that you started this work. Please, excuse my dumb
> > questions, I just want to understand the subject and its correlations
> > to other activities better
> >
> > 1. Does you patch capture an output from crashed VM? This would be
> > quite useful, because VM prints a native stack trace when crashes.
>
> It can but it does not. Now it just reports about failed test case.
>
> > 2. I support Alexei's question about functional differences between
> > Vladimir's approach and your one. As for now I more or less understand
> > why Vladimir's solution is good (simple and catches crashes with zero
> > return code), and understand why it is bad (it doesn't capture VM's
> > output).
>
> Other laks of his approach are: it does not capture the situations
> when JVM crashed before creation of xml file (there are such tests)
> and it does not report test case made JVM crash (only JUnit test class
> name). Although I agree - his aproach is simpler.
>
> > 3. Can your solution be extended to modes other than perTest (for
> > example, to test reliability on simple cases)?
>
> Yes, it is possible to implement, but now I do not see the sense of
> doing it. If one test in a bundle causes JVM crash there won't be a
> chance for other test (in a bundle) to be executed.
>
> > 4. You wrote,
> > > Note that H000 regression test is failed because of DRLVM crash.
> >
> > Have I missed something? What is this H000?
>
> This is an example of regression test placed under
> src/test/regression/H000 directory. Now there is no corresponding JIRA
> report for it. I'm going to remove it when I finish infrastructure (and
> file new JIRA report if there is no such).
>
> > 5. Is there anything Harmony specific in your task? Could it be useful
> > for Ant project?
>
> JUnit test format is not supposed to handle JVM crashes. So I think it
> is Harmony specific. Particularly to its VM part.
>
> > 6. Is it difficult to add handling of test decorators in a following way?
> >
> >  <junitperf fork="false">
> >      <decorator class="junit.extensions.RepeatedTest">
> >            <ctorarg test/>
> >            <ctorarg intvalue="${junit.extensions.repeatedtest.repetions}"/>
> >      </decorator>
> >      <test name="org.apache.ecs.InternationalCharTest" />
> >  </junitperf>
>
> I don't know exactly, but first ideas coming in my head are:
>    - extending of a JUnitRunner class to execute decorator with a unit
>    test as a parameter
>    - extending of JUnitTask to handle nested <decorator> elements
>    and to configure command line to be launched).
>
> > (I just oticed that posted this example privately).
> >
> > To my mind idea is quite promising, and I even have started to
> > interfere with your field. You could think of a decorator which
> > preallocates a big amount of memory and runs given tests in the rest
> > of the heap space, or a decorator which runs GC in parallel, or even a
> > decorator which runs all tests on a finalization thread.
> >
> > I put two coffees for the fact that the last decorator to class
> > library unit tests would produce many interesting DRLVM artifacts and
> > JIRA issues.
>
> I agree, it is a good idea!
>
> > Alexander, thanks again for starting this job! All, thank you for
> > reading up to this point. :-)
>
> Thank you for your interest! I think at the moment I've got everything
> I needed from <junit> task. If there is a person who is willing to
> continue these improvements I'll happy to help him.
>
> Alexander
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message