Well, we all learned the lesson. Here are my own thoughts, and some
more answers are inlined:
1) Explicit separate testing for all execution engines (JET, OPT,
interpreter) is really valuable; so far we found bugs in many
components including classlib (!), especially due to interpreter. I
bet JIT
2006/11/16, Tim Ellison <[EMAIL PROTECTED]>:
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.
2006/11/16, Gregory Shimansky <[EMAIL PROTECTED]>:
Alexey Varlamov wrote:
> 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
>
There is something that I am missing here. For example on my Linux build,
running kernel tests with .jet, I see some java.lang tests failures eg.,
SystemExtensionTest fails for me, and in the console summary report I get
"Kernel tests failed using Jitrino.Jet blah blah", but when I go browse
repor
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.
Hmm, this doesn't sound right. I've not seen
Rana Dasgupta wrote:
I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.
We can't depend on this - they have to mechani
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 ra
I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.
On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
Guys,
This is
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 co
Alexey Varlamov wrote:
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.
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
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
=
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)
++
2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
Alexey Varlamov wrote:
> 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
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 fr
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 do
Alexey Varlamov wrote:
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 enable
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 s
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?
Actually if you revert the
All,
I wonder if we should apply "zero regression" policy to this change.
Speaking simply, should this patch be reverted and kept for additional
investigation?
On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTIO
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/ex
Heh, this regression is more interesting than it looked at first glance:
JITs give the same output with identical stack trace, but test result is PASSED.
By lucky chance I have older debug build at hand (svn = r474646) and
it also spills this stacktrace to system err but status is PASSED for
all e
22 matches
Mail list logo
