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 gshimansky@gmail.com
 designates 64.233.184.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=WGqeEykndSLrT597oa/nTLdnnFKN6eySpzT3v9rVmaq16L6Sc3pooK0gATm9Xm06jo2qR8y1gXFeCub9xUbgGtsENa9kFoSwqvLXmbqWUjQ0jv4gHua5NGf0vzRPNPyz3abYAfBPz+tM5/98jnozUt76gaFZIa7anVD7CKGZmyY=
Message-ID: <475EAD4D.1080509@apache.org>
Date: Tue, 11 Dec 2007 18:31:25 +0300
From: Gregory Shimansky <gshimansky@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Created: (HARMONY-5290) [drlvm][jit] SIGSEGV in JIT code
References: <20310275.1197359323280.JavaMail.jira@brutus>
	 <475E7BA4.5050500@gmail.com>
	 <469bff730712110632u6de62bf7if850c26e7c969379@mail.gmail.com>
 <469bff730712110650s40c32551raa87a1ac03cab44e@mail.gmail.com>
In-Reply-To: <469bff730712110650s40c32551raa87a1ac03cab44e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregory Shimansky <gshimansky@gmail.com>

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