harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Leviev (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-3900) [drlvm][thread] Race condition at thread_native_thin_monitor.c:(675,654)
Date Thu, 17 May 2007 14:33:16 GMT
[drlvm][thread] Race condition at thread_native_thin_monitor.c:(675,654)
------------------------------------------------------------------------

                 Key: HARMONY-3900
                 URL: https://issues.apache.org/jira/browse/HARMONY-3900
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
            Reporter: Ilya Leviev




TC report on thread unsafe access that result in race condition that occur during concurrent
execution of locktable_put_fat_monitor and locktable_get_fat_monitor functions.


Write -> Read data-race	
Memory read at "thread_native_thin_monitor.c":654 conflicts with a prior memory write at "thread_native_thin_monitor.c":675




Stack Trace: 


Context
	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 hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":341
	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
	Function jthread_monitor_enter "thread_java_monitors.c":117
	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":309
	Function locktable_get_fat_monitor "thread_native_thin_monitor.c":649


1st Access (Write)
	Function m2n_free_local_handles "m2n_ia32.cpp":268
	Function hythread_self "hythread.h":465
	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 hythread_suspend_enable "hythread_ext.h":370
	Function Java_java_lang_VMThreadManager_wait "java_lang_vmthreadmanager.cpp":202
	Function jthread_monitor_timed_wait "thread_java_monitors.c":308
	Function inflate_lock "thread_native_thin_monitor.c":599
	Function locktable_put_fat_monitor "thread_native_thin_monitor.c":675


"674"	""	" "
"675"	"*"	"     lock_table[id] = fat_monitor;"
"676"	""	"     //hythread_global_unlock();"


2nd Access (Read)
	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 hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":341
	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
	Function jthread_monitor_enter "thread_java_monitors.c":117
	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":309
	Function locktable_get_fat_monitor "thread_native_thin_monitor.c":654


"652"	""	"     assert(lock_id >=0 && lock_id < table_size);"
"653"	""	"     //hythread_global_lock();"
"654"	"*"	"     fat_monitor = lock_table[lock_id];"
"655"	""	"     //hythread_global_unlock();"
"656"	""	"     return fat_monitor;"



See also Source View screenshot.



Notes on Write->Read race conditions.
---------------------------------------------------
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.


Mime
View raw message