You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ilya Leviev (JIRA)" <ji...@apache.org> on 2007/05/29 10:14:16 UTC
[jira] Updated: (HARMONY-3920) [drlvm][thread][tc] Race conditions
at "apr_atomic.c":102" and thread_native_thin_monitor.c:502
[ https://issues.apache.org/jira/browse/HARMONY-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Leviev updated HARMONY-3920:
---------------------------------
Summary: [drlvm][thread][tc] Race conditions at "apr_atomic.c":102" and thread_native_thin_monitor.c:502 (was: [drlvm][tc][thread] Race conditions at "apr_atomic.c":102" and thread_native_thin_monitor.c:502)
> [drlvm][thread][tc] Race conditions at "apr_atomic.c":102" and thread_native_thin_monitor.c:502
> -----------------------------------------------------------------------------------------------
>
> Key: HARMONY-3920
> URL: https://issues.apache.org/jira/browse/HARMONY-3920
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> 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_notify functions.
> Write -> Read data-race
> Memory read at "thread_native_thin_monitor.c":502 conflicts with a prior memory write at "apr_atomic.c":102
> Stack Trace:
> Context
> 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 hythread_suspend_enable "hythread_ext.h":370
> Function Java_java_lang_VMThreadManager_notify "java_lang_vmthreadmanager.cpp":96
> Function jthread_monitor_notify "thread_java_monitors.c":222
> Function hythread_thin_monitor_notify "thread_native_thin_monitor.c":500
> 1st Access
> 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":223
> 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""));"
> 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
> 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 hythread_suspend_enable "hythread_ext.h":370
> Function Java_java_lang_VMThreadManager_notify "java_lang_vmthreadmanager.cpp":96
> Function jthread_monitor_notify "thread_java_monitors.c":222
> Function hythread_thin_monitor_notify "thread_native_thin_monitor.c":502
> "500" "" " IDATA hythread_thin_monitor_notify(hythread_thin_monitor_t *lockword_ptr) {"
> "501" "" " hythread_monitor_t fat_monitor;"
> "502" "*" " hythread_thin_monitor_t lockword = *lockword_ptr;"
> "503" "" " if (IS_FAT_LOCK(lockword)) {"
> "504" "" " fat_monitor = locktable_get_fat_monitor(FAT_LOCK_ID(lockword));"
> 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.