Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of ivavladimir@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=mCxRLuCBS6ji6G+n8cmk06iPoeP4romrZkJcJa8pCahbDolmTZ/exmNM3Sj6CedVMIUizKWaT8vbn7hewdH4HA6jFW3N744mrwoKkwDQA/buMt+2fZc0cXYfnLIvxkXuGwcnu5fNUeQe05gIMiOfQmWQUhDNmJolLZnN7MuPolE=
Message-ID: <7273946b0612070439l3130a359x231a39f8f0e56bd9@mail.gmail.com>
Date: Thu, 7 Dec 2006 18:39:34 +0600
From: "Vladimir Ivanov" <ivavladimir@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general][testing] need a piece of advise: how we can handle VM
 crashes
In-Reply-To: <e09a11790612070212o49106e5an2edc3ea1c9555044@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_52734_28527452.1165495174054"
References: <7273946b0611230507j19db48dfw9404d0ed00e99532@mail.gmail.com>
	 <c30d70960611291024w13dfafb5k1c13a44550192a0d@mail.gmail.com>
	 <7273946b0612010504w6ceeac3csfe338fb6126453c7@mail.gmail.com>
	 <e09a11790612050048o575bbd6td9cebda36971a579@mail.gmail.com>
	 <2c9597b90612050643u4ecb0ba6l9f44db2eb70d133c@mail.gmail.com>
	 <e09a11790612060311x72f35331s737a7d69fbf69bc@mail.gmail.com>
	 <7273946b0612060411q27141af0v23c647fb0eebb5e6@mail.gmail.com>
	 <2c9597b90612060817l8a484fer5a014b558f1bf03b@mail.gmail.com>
	 <c30d70960612061105p34e2a3e2udb85d0e7886af002@mail.gmail.com>
	 <e09a11790612070212o49106e5an2edc3ea1c9555044@mail.gmail.com>

------=_Part_52734_28527452.1165495174054
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_52734_28527452.1165495174054--