harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [general][testing] need a piece of advise: how we can handle VM crashes
Date Thu, 07 Dec 2006 14:33:56 GMT
Alexander Kleymenov wrote:
> > > 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.

If forkMode set to "perTest" then the test execution cycle takes much
longer than if it set to "once". So if "perTest" is hardcoded then I'm
afraid using your ant task in its current state instead of the
standard one can cause too much pain. At least for classlib test runs.

Vladimir Ivanov wrote:
> I suggest integrating Alexander's implementation. If it wills not enough we
> can add special handling for zero-length file (it is very simple :)).

Ok. I have nothing against Alexander's patch, but all files to be
patched are lying inside DRLVM workspace and the patch in its current
form cannot be used for classlib, so I'm leaving it to DRLVM
commiters. Personally I've never seen the situation then VM crashes
(on classlib tests) without zero-length report file being generated.
Vladimir's solution is very simple and solves one particular problem.
Since I'd like this problem to be fixed (at least for some classlib
modules) and like the simplicity of HARMONY-2349 I still going to
commit it for example for archive and for beans modules. If someone
objects please rise your hands.
When something more exciting will be ready for classlib we can switch to it.

Thanks,

2006/12/7, Vladimir Ivanov <ivavladimir@gmail.com>:
> I suggest integrating Alexander's implementation. If it wills not enough we
> can add special handling for zero-length file (it is very simple :)).
>
>
>
>  Thanks, Vladimir
>
>
> 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.


-- 
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Mime
View raw message