harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "weldon washburn (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-3912) [drlvm][thread][tc] Race conditions at "thread_native_thin_monitor.c":78 and "thread_java_monitors.c":361/362
Date Tue, 09 Oct 2007 21:03:51 GMT

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

weldon washburn updated HARMONY-3912:
-------------------------------------

    Priority: Minor  (was: Major)

> [drlvm][thread][tc] Race conditions at "thread_native_thin_monitor.c":78 and "thread_java_monitors.c":361/362
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-3912
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3912
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: win2003
>            Reporter: Ilya Leviev
>            Priority: Minor
>         Attachments: SourceViewScreenshot-1.jpg
>
>
> TC report on thread unsafe access that result in 2 race conditions that occur during
concurrent execution of set_fat_lock_id and hythread_thin_monitor_enter functions.
> Write -> Read data-race	
> Memory read at "thread_native_thin_monitor.c":361 conflicts with a prior memory write
at "thread_native_thin_monitor.c":78
> Write -> Read data-race	
> Memory read at "thread_native_thin_monitor.c":362 conflicts with a prior memory write
at "thread_native_thin_monitor.c":78
> Stack Trace: 
> Context
> 	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":341
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function jthread_monitor_enter "thread_java_monitors.c":123
> 	Function hythread_thin_monitor_enter "thread_native_thin_monitor.c":349
> 1st Access
> 	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":341
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function jthread_monitor_enter "thread_java_monitors.c":135
> 	Function inflate_lock "thread_native_thin_monitor.c":600
> 	Function set_fat_lock_id "thread_native_thin_monitor.c":78
> "76"	""	"     lockword&=0x7FF;"
> "77"	""	"     lockword|=(monitor_id << 11) | 0x80000000;"
> "78"	"*"	"     *lockword_ptr=lockword;"
> "79"	""	"     apr_memory_rw_barrier();"
> 2nd Access
> 	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":341
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function jthread_monitor_enter "thread_java_monitors.c":123
> 	Function hythread_thin_monitor_enter "thread_native_thin_monitor.c":361/362
> "360"	""	"     while (hythread_thin_monitor_try_enter(lockword_ptr) == TM_ERROR_EBUSY)
{"
> "361"	"*"	"         if (IS_FAT_LOCK(*lockword_ptr)) {"
> "362"	"*"	"             fat_monitor = locktable_get_fat_monitor(FAT_LOCK_ID(*lockword_ptr));
//  find fat_monitor in lock table"
> "363"	""	"             TRACE(("" lock %d\n"", FAT_LOCK_ID(*lockword_ptr)));"
> "364"	""	"             saved_disable_count=reset_suspend_disable();"
> See also Source View screenshot.
> 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.


Mime
View raw message