Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <31229228.1180423696091.JavaMail.jira@brutus>
Date: Tue, 29 May 2007 00:28:16 -0700 (PDT)
From: "Ilya Leviev (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-3924) [drlvm][tc][thread] Race conditions
 at "apr_atomic.c":102 and "thread_native_thin_monitor.c":276
In-Reply-To: <14441436.1179754235522.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilya Leviev updated HARMONY-3924:
---------------------------------

    Summary: [drlvm][tc][thread] Race conditions at "apr_atomic.c":102 and "thread_native_thin_monitor.c":276  (was: [drlvm][thread] Race conditions at "apr_atomic.c":102 and "thread_native_thin_monitor.c":276)

> [drlvm][tc][thread] Race conditions at "apr_atomic.c":102 and "thread_native_thin_monitor.c":276
> ------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-3924
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3924
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: win2003
>            Reporter: Ilya Leviev
>         Attachments: SourceViewScreenshot-1.jpg, SourceViewScreenshot-2.jpg
>
>
> TC report on thread unsafe access that result in race condition that occur during concurrent execution of apr_atomic_cas32 and hythread_thin_monitor_try_enter functions.
> Write -> Read data-race	
> Memory read at "thread_native_thin_monitor.c":276 conflicts with a prior memory write at "apr_atomic.c":102
> Stack Trace: 
> Context
> 	Function void vm_execute_java_method_array(struct _jmethodID *,union jvalue *,union jvalue *) "ini.cpp":60
> 	Function ExecuteMethod "em_intf.cpp":43
> 	Function void DrlEMImpl::executeMethod(struct _jmethodID *,union jvalue *,union jvalue *) "drlemimpl.cpp":509
> 	Function void JIT_execute_method_default(void *,struct _jmethodID *,union jvalue *,union jvalue *) "ini_ia32.cpp":199
> 	Function vm_invoke_native_array_stub "ini_ia32.cpp":76
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":233
> 1st Access - Write 
> 	Function void DrlEMImpl::executeMethod(struct _jmethodID *,union jvalue *,union jvalue *) "drlemimpl.cpp":509
> 	Function void JIT_execute_method_default(void *,struct _jmethodID *,union jvalue *,union jvalue *) "ini_ia32.cpp":199
> 	Function vm_invoke_native_array_stub "ini_ia32.cpp":76
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":323
> 	Function unreserve_lock "thread_native_thin_monitor.c":180
> 	"179"	""	"         if (lockword == apr_atomic_cas32 (((volatile apr_uint32_t*) lockword_ptr), "
> 	"180"	""	"                 (apr_uint32_t) lockword_new, lockword)) {"
> 	"181"	""	"             TRACE((""unreserved lock""));"
> 	"182"	""	"             break;"
> 	Function apr_atomic_cas32 "apr_atomic.c":102
> 	"96"	""	" APR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile apr_uint32_t *mem, apr_uint32_t with,"
> 	"97"	""	"                                            apr_uint32_t cmp)"
> 	"98"	""	" {"
> 	"99"	""	" #if (defined(_M_IA64) || defined(_M_AMD64)) && !defined(RC_INVOKED)"
> 	"100"	""	"     return InterlockedCompareExchange(mem, with, cmp);"
> 	"101"	""	" #else"
> 	"102"	"*"	"     return ((apr_atomic_win32_ptr_val_val_fn)InterlockedCompareExchange)(mem, with, cmp);"
> 	"103"	""	" #endif"
> 	"104"	""	" }"
> 2nd Access - Read
> 	Function void vm_execute_java_method_array(struct _jmethodID *,union jvalue *,union jvalue *) "ini.cpp":60
> 	Function ExecuteMethod "em_intf.cpp":43
> 	Function void DrlEMImpl::executeMethod(struct _jmethodID *,union jvalue *,union jvalue *) "drlemimpl.cpp":509
> 	Function void JIT_execute_method_default(void *,struct _jmethodID *,union jvalue *,union jvalue *) "ini_ia32.cpp":199
> 	Function vm_invoke_native_array_stub "ini_ia32.cpp":76
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":276
> 	"275"	""	" #ifdef SPIN_COUNT"
> 	"276"	"*"	"     for (i = SPIN_COUNT; i >=0; i--, lockword = *lockword_ptr, lock_id = THREAD_ID(lockword)) { "
> 	"277"	""	" #endif"
> See also Source View screenshots.
> Notes on Write->Read race condition.
> ------------------------------------
> Write->Read data races occur when one thread writes a shared memory location (address) while another thread concurrently reads the same memory location.  
> The shared memory location may be referred to by (variable) name, pointer, or even a function such as memcpy().  
> The following example uses a variable name:
> 1st access by first thread
> S1: sharedX = privateA
> 2nd access by second thread
> S2: privateB = sharedX
> If sharedX is a variable visible to all threads and privateA and privateB are local variables visible only to the thread where each was declared,
>  concurrent execution of the above statements by multiple threads results in a "race" on the value to be read from sharedX.   
> Since the order of execution among threads is unpredictable, it is unknown which value will be available in sharedX to be stored into privateB.  
> This results in non-deterministic software, or software prone to produce different results each time it is executed. 
> _______________________________________________________________________________________________________________________
> If it not affect correctness of execution I will mark it by special API for prevention of further alarms on this race.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.