-
Type: Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
-
None
I am sometimes seeing a crash/hang in shared_cache04. On the surface it appears that the test completes and closes before one thread gets started. This happened to me today about 50% of the tries. Stacks:
(gdb) thread apply all bt Thread 2 (process 76664): WT-3 0x000000010f3f6512 in __wt_abort (session=0x7feee7816000) at os_abort.c:21 WT-4 0x000000010f423bf4 in __wt_assert (session=0x7feee7816000, error=0, file_name=0x10f43fed2 "../src/session/session_api.c", line_number=838, fmt=0x10f436528 "%s") at err.c:452 WT-5 0x000000010f41f693 in __wt_open_session (conn=0x7feee7802000, event_handler=0x0, config=0x0, sessionp=0x10f900e40) at session_api.c:838 WT-6 0x000000010f41f4bb in __wt_open_internal_session (conn=0x7feee7802000, name=0x10f43c771 "cache-pool", uses_dhandles=0, open_metadata=0, sessionp=0x7feee3654b78) at session_api.c:758 WT-7 0x000000010f3a65d2 in __cache_pool_balance () at conn_cache_pool.c:353 WT-8 0x000000010f3a6ecc in __wt_cache_pool_server (arg=0x0) at conn_cache_pool.c:542 Thread 1 (process 76664): #0 0x00007fff8d3aa122 in __psynch_mutexwait () WT-1 0x00007fff8e2dcdfd in pthread_mutex_lock () WT-2 0x000000010f41aefc in __wt_spin_lock (session=0x7feee7816280, t=0x7feee7802300) at mutex.i:172 WT-3 0x000000010f41abbd in __session_close (wt_session=0x7feee7816280, config=0x0) at session_api.c:119 WT-4 0x000000010f351605 in __wt_evict_destroy (conn=0x7feee7802000) at bt_evict.c:329 WT-5 0x000000010f3aba58 in __wt_connection_close (conn=0x7feee7802000) at conn_open.c:151 WT-6 0x000000010f3a18d3 in __conn_close (wt_conn=0x7feee7802000, config=0x0) at conn_api.c:614 WT-7 0x000000010f30ed9d in _wrap_Connection_close (self=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at ../../../lang/python/wiredtiger_wrap.c:7148
And here is the assertion:
/* * Make sure we don't try to open a new session after the application * closes the connection. This is particularly intended to catch * cases where server threads open sessions. */ WT_ASSERT(session, F_ISSET(conn, WT_CONN_SERVER_RUN));
Perhaps instead of an assert, if the flag isn't set and this thread lost a scheduling race, it should unlock and return?
- is related to
-
WT-1180 Fix session management for shared caches.
- Closed
- related to
-
WT-1 placeholder WT-1
- Closed
-
WT-2 What does metadata look like?
- Closed
-
WT-3 What file formats are required?
- Closed
-
WT-4 Flexible cursor traversals
- Closed
-
WT-5 How does pget work: is it necessary?
- Closed
-
WT-6 Complex schema example
- Closed
-
WT-7 Do we need the handle->err/errx methods?
- Closed
-
WT-8 Do we need table load, bulk-load and/or dump methods?
- Closed