Alexei Fedotov wrote:
Guys,
This is a good discussion, and let me praise Alexey for the wonderful fix.
I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?
Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?
I saw that they failed on interpreter and saw an additional failure by
ClassGeneticsTest4, but when I reverted the patch I ran the test
individually (because running kernel tests is quite a long task). I saw
exceptions output from ClassGeneticsTest4 with reverted patch and
decided that it wasn't the one to blame. I tried reverting other patches
but all of them produced the same output. Today Alexey explained to me
that exceptions output was just a verbose test output not to related to
test passed/failed status. So the answer to your question is "not very
clearly" :)
After I saw that reverting the patches doesn't help very much I decided
that regression somehow slipped earlier but wasn't noticed. The problem
with kernel tests is that they don't pass stably. Often j.l.ThreadTest
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
result of kernel tests run was assumed to be ok because
ClassGeneticsTest4 failure was not noticed since some tests which fail
often failed.
The output of kernel tests is not very good too. They run 3 times on
JET, OPT and interpreter. The last output is for interpreter, and if the
output prints PASSED it is necessary to check result for JET and OPT. I
think the tests should either <fail/> after the first test run which
didn't pass (similar to how smoke tests stop tests execution), or print
a summary at the end for all 3 runs with <fail/> if case any of them
didn't pass.
On 11/15/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> Pardon for my English - a bit sleepy already...
>
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===============================================================
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > - jthrowable exc_cause = oh_allocate_local_handle();
> > + exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
> >
> >
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > >> > Alexey Varlamov wrote:
> > > >> > > The guilty change is the following, which effectively
turns on
> > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > >> >
> > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> fact that
> > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > >
> > > > Gregory,
> > > >
> > > > I've just re-read my posts and couldn't find anything critique or
> > > > offending - please don't take regressions too personal. I'm
sure we
> > > > will be able to fix this one quite soon.
> > >
> > > I wasn't offended in any way. I was just thinking that you know
some
> > > secret knowledge that lazy exceptions do not work and thus enabling
> them
> > > is wrong.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>
--
Gregory
