-
Type:
Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
-
None
Automated testing today found a race in the new code that puts eviction requests into the session handle.
A thread was waiting for a sync:
Thread 2 (Thread 0x7f693ffff700 (LWP 25683)): #0 0x00000030f380b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 WT-1 0x000000000040eb7c in __wt_cond_wait (session=0x1db44d0, cond=0x7f6920012980) at ../src/os_posix/os_mtx.c:68 WT-2 0x0000000000424036 in __wt_session_serialize_func (session=0x1db44d0, op=WT_SERIAL_EVICT, func=0x419c57 <__wt_sync_file_serial_func>, args=0x7f693fffeb20) at ../src/include/serial.i:54 WT-3 0x0000000000424086 in __wt_sync_file_serial (session=0x1db44d0, syncop=1) at ../src/include/serial_funcs.i:321 WT-4 0x0000000000424a0a in __wt_cache_flush (session=0x1db44d0, op=1) at ../src/btree/bt_sync.c:307
But the eviction thread was sleeping, believing it had handled all requests:
Thread 5 (Thread 0x7f694d39b700 (LWP 25667)): #0 0x00000030f380b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 WT-1 0x000000000040eb7c in __wt_cond_wait (session=0x1db39e0, cond=0x1dc1d70) at ../src/os_posix/os_mtx.c:68 WT-2 0x0000000000419e96 in __wt_cache_evict_server (arg=0x1db3210) at ../src/btree/bt_evict.c:273
(gdb) print *((WT_CONNECTION_IMPL *)$2)->cache
$4 = {..., sync_request = 99, sync_complete = 99}
I'm about to push a change that should catch this, but I can't yet see how where the race is happening.
Michael.