Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of
 andrey.a.pavlenko@googlemail.com designates 64.233.184.227 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=NeSwJCYG1rDkQxhbXLK9+2wwooqkuA/NFZqHq/nagKv79UQyKmEoBfu3djkWbCPkh7C+PyaXwH7ntt2/6tzV3m52uqGidiKEAM30dhRlE3GWiBHOlGMHrt+AmXphNkGkWbbVsw3WtNtUt19ojZYMRnFHUef0zNqxvUGMpND3IK4=
Message-ID: <af4b1ec30712111126p1014d7b9h1757d08d3db9ce4e@mail.gmail.com>
Date: Tue, 11 Dec 2007 22:26:22 +0300
From: "Pavlenko, Andrey A" <andrey.a.pavlenko@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [jira] Created: (HARMONY-5290) [drlvm][jit] SIGSEGV in JIT code
In-Reply-To: <475EAD4D.1080509@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15195_14720122.1197401182879"
References: <20310275.1197359323280.JavaMail.jira@brutus>
	 <475E7BA4.5050500@gmail.com>
	 <469bff730712110632u6de62bf7if850c26e7c969379@mail.gmail.com>
	 <469bff730712110650s40c32551raa87a1ac03cab44e@mail.gmail.com>
	 <475EAD4D.1080509@apache.org>

------=_Part_15195_14720122.1197401182879
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

+1 to commit.

Gregory, actually the test mentioned in JIRA also crashed on Windows but
with different stack. However, I can't reproduce it.

On 12/11/07, Gregory Shimansky <gshimansky@apache.org> wrote:
>
> Pavel Ozhdikhin said the following on 11.12.2007 17:50:
> > Hello all,
> >
> > According to our code freeze rules we need approval from 2 committers to
> > commit the patch from https://issues.apache.org/jira/browse/HARMONY-5290
> >
> > The bug is a regression causing DRLVM crash on several functional and
> > reliability tests. The bug is not platform-specific and the fix looks
> safe.
> >
> > Committers, please vote.
>
> +1 to commit the fix, but since the bug was filed on Linux I think it
> should be checked on Linux as well.
>
> > On 12/11/07, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> >> The fix is in JIRA, I'm running tests to check it.
> >>
> >> Thanks,
> >> Pavel
> >>
> >>
> >>  On 12/11/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >>> This issue does seem to be the cause of a number of current test
> >>> failures.
> >>> Anyone care to take ownership of it?
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>> Andrey Pavlenko (JIRA) wrote:
> >>>> [drlvm][jit] SIGSEGV in JIT code
> >>>> --------------------------------
> >>>>
> >>>>                  Key: HARMONY-5290
> >>>>                  URL:
> >>> https://issues.apache.org/jira/browse/HARMONY-5290
> >>>>              Project: Harmony
> >>>>           Issue Type: Bug
> >>>>           Components: DRLVM
> >>>>          Environment: Linux x86/x64
> >>>>             Reporter: Andrey Pavlenko
> >>>>             Priority: Critical
> >>>>
> >>>>
> >>>> The following test causes VM crash.  I've marked this issue as
> >>> critical because it seems to be a regression and causes an error of
> the
> >>> functional test
> http://people.apache.org/~smishura/r602572/Linux_x86/func/functional/org/apache/harmony/test/func/jit/HLO/peel/LoopVar2/738_LoopVar2.html
> >>>
> >>>> public class Test {
> >>>>
> >>>>     boolean flag = false;
> >>>>
> >>>>     public static void main(String[] args) {
> >>>>         System.exit((new Test()).test());
> >>>>     }
> >>>>
> >>>>     public int test() {
> >>>>         int limit = 100000;
> >>>>         int i = -1;
> >>>>         int k = -1;
> >>>>         while (k < limit) {
> >>>>             k++;
> >>>>             for (i = 0; i < k; i++) {
> >>>>                 flag = true;
> >>>>             }
> >>>>         }
> >>>>         return ((k == limit) && (i == limit)) ? 0 : 1;
> >>>>     }
> >>>> }
> >>>>
> >>>> SIGSEGV in VM code.
> >>>> Stack trace:
> >>>>   0: Jitrino::ControlFlowGraph::addEdge(Jitrino::Node*,
> >>> Jitrino::Node*, Jitrino::Edge*, double) ( walkers.cpp:-1)
> >>>>   1: Jitrino::ControlFlowGraph::addEdge(Jitrino::Node*,
> >>> Jitrino::Node*, double) (walkers.cpp:-1)
> >>>>   2:
> Jitrino::FlowGraph::doTranslatorCleanupPhase(Jitrino::IRManager&)
> >>> (walkers.cpp:-1)
> >>>>   3: Jitrino::TranslatorSession::postTranslatorCleanup() (
> >>> walkers.cpp:-1)
> >>>>   4: Jitrino::TranslatorSession::run() (walkers.cpp:-1)
> >>>>   5: Jitrino::runPipeline(Jitrino::CompilationContext*) (
> >>> walkers.cpp:-1 )
> >>>>   6: Jitrino::compileMethod(Jitrino::CompilationContext*) (
> >>> walkers.cpp:-1)
> >>>>   7: Jitrino::Jitrino::CompileMethod(Jitrino::CompilationContext*) (
> >>> walkers.cpp:-1)
> >>>>   8: JIT_compile_method_with_params (??:-1)
> >>>>   9: Dll_JIT::compile_method_with_params(void*, Method*,
> >>> OpenMethodExecutionParams) (apr_strtok.c:-1)
> >>>>  10: compile_do_compilation_jit(Method*, JIT*) (apr_strtok.c:-1)
> >>>>  11: vm_compile_method (??:-1)
> >>>>  12: DrlEMImpl::methodProfileIsReady(MethodProfile*) (inet_pton.c:-1)
> >>>>  13: EBProfileCollector::onTimeout() (inet_pton.c:-1)
> >>>>  14: DrlEMImpl::tbsTimeout() (inet_pton.c:-1)
> >>>>  15: ProfilerThreadTimeout (em_intf.cpp:-1)
> >>>>  16: Java_java_lang_EMThreadSupport_onTimeout (??:-1)
> >>>>  17: 0xA6093C26  <Generated stub>
> >>>>  18: java/lang/EMThreadSupport.run()V (EMThreadSupport.java:68)
> >>>>  19: java/lang/EMThreadSupport$1.run()V ( EMThreadSupport.java:44)
> >>>>  20: java/lang/Thread.run()V (Thread.java:657)
> >>>>  21: java/lang/Thread.runImpl()V (Thread.java:668)
> >>>>  22: ?? (??:-1)
> >>>>  23: .L294 (ini_iA32.cpp:-1)
> >>>>  24: DrlEMImpl::executeMethod(_jmethodID*, jvalue*, jvalue*)
> >>> (inet_pton.c:-1)
> >>>>  25: ExecuteMethod (em_intf.cpp:-1)
> >>>>  26: vm_execute_java_method_array (apr_strtok.c:-1)
> >>>>  27: call_method_no_ref_result(JNIEnv_External*, _jobject*,
> >>> _jmethodID*, jvalue*, jvalue*, int) (jni_method.cpp:-1)
> >>>>  28: CallVoidMethodA(JNIEnv_External*, _jobject*, _jmethodID*,
> >>> jvalue*) (apr_strtok.c:-1)
> >>>>  29: jthread_wrapper_start_proc(void*) (apr_strtok.c:-1)
> >>>>  30: start_thread (??:-1)
> >>>>  31: clone (??:-1)
> >>>> <end of stack trace>
> >>>> Segmentation fault
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
>
>

------=_Part_15195_14720122.1197401182879--