You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "weldon washburn (JIRA)" <ji...@apache.org> on 2007/10/10 17:22:51 UTC

[jira] Closed: (HARMONY-3914) [drlvm][thread][tc] Race conditions at "thread_native_basic.c":(480,275)

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

weldon washburn closed HARMONY-3914.
------------------------------------

    Resolution: Won't Fix

> [drlvm][thread][tc] Race conditions at "thread_native_basic.c":(480,275)
> ------------------------------------------------------------------------
>
>                 Key: HARMONY-3914
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3914
>             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 race condition that occur during concurrent execution of hythread_get_thread and hythread_detach functions.
> Read -> Write data-race	
> Memory write at "thread_native_basic.c":275 conflicts with a prior memory read at "thread_native_basic.c":480
> Stack Trace: 
> Context
> 	Function jthread_create "thread_java_basic.c":63
> 	Function jthread_create_with_function "thread_java_basic.c":179
> 	Function hythread_create "thread_native_basic.c":165
> 	Function hythread_create_with_group "thread_native_basic.c":136
> 	Function os_thread_create "os_thread.c":37
> 	Function _beginthreadex "threadex.c":145
> 	Function EntryPoint "dllcrt0.c":323
> 	Function threadstartex "threadex.c":241
> 	Function thread_start_proc "thread_native_basic.c":720
> 	Function hythread_detach "thread_native_basic.c":259
> 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":88
> 	Function unreserve_lock "thread_native_thin_monitor.c":151
> 	Function hythread_get_thread "thread_native_basic.c":480
> "479"	""	" hythread_t VMCALL hythread_get_thread(IDATA id) {"
> "480"	"*"	"     return fast_thread_array[id];"
> "481"	""	" }"
> 2nd Access
> 	Function jthread_create "thread_java_basic.c":63
> 	Function jthread_create_with_function "thread_java_basic.c":179
> 	Function hythread_create "thread_native_basic.c":165
> 	Function hythread_create_with_group "thread_native_basic.c":136
> 	Function os_thread_create "os_thread.c":37
> 	Function _beginthreadex "threadex.c":145
> 	Function EntryPoint "dllcrt0.c":323
> 	Function threadstartex "threadex.c":241
> 	Function thread_start_proc "thread_native_basic.c":720
> 	Function hythread_detach "thread_native_basic.c":275
> "274"	""	"         thread_set_self(NULL);"
> "275"	"*"	"         fast_thread_array[thread->thread_id] = NULL;"
> "276"	""	"         "
> See also Source View screenshot.
> Notes on Read->write race condition.
> ------------------------------------
> Read->write data races occur when one thread reads a shared memory location (address) while another thread concurrently writes 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: privateA = sharedX 
> 2nd access by second thread
> S2: sharedX = privateB 
> 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 what value will be read from sharedX and written into privateA.
> 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.