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_EXCEPTION
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
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
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 enables
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
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
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 patch from
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)
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
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
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
===
---
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
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
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
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
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
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
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.
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
Hello
Today a kernel tests which used to pass a day ago started to fail. It is
java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
and classlib (since some important classes like URLClassLoader, Hashtable and
TreeMap were changed recently) patches but no reversion
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
21 matches
Mail list logo
