The WT_WITH_TABLE_LOCK assertion failed in https://jira.mongodb.org/browse/SERVER-16967. This implies a potential deadlock situation. The stack is:
wiredtiger\src\support\err.c(451) __wt_assert+0x37 wiredtiger\src\schema\schema_list.c(28) __schema_add_table+0x6c wiredtiger\src\schema\schema_list.c(99) __wt_schema_get_table+0x64 wiredtiger\src\schema\schema_worker.c(83) __wt_schema_worker+0x2ee wiredtiger\src\txn\txn_ckpt.c(132) __checkpoint_apply_all+0x1d1 wiredtiger\src\txn\txn_ckpt.c(346) __wt_txn_checkpoint+0x1ca wiredtiger\src\session\session_api.c(889) __session_checkpoint+0x1b3 wiredtiger\src\session\session_compact.c(185) __compact_file+0x101 wiredtiger\src\session\session_compact.c(235) __wt_session_compact+0x250
The WT_WITH_TABLE_LOCK macro asserts that we do not hold the dhandle_lock and we do. In this stack we acquire the dhandle_lock up in __wt_txn_checkpoint in this code:
/*
* Get a list of handles we want to flush; this may pull closed objects
* into the session cache, but we're going to do that eventually anyway.
*/
WT_WITH_SCHEMA_LOCK(session,
WT_WITH_DHANDLE_LOCK(session,
ret = __checkpoint_apply_all(
session, cfg, __wt_checkpoint_list, NULL)));
In looking at the locking hierarchy, it appears, based on the WT_WITH_*_LOCK macros, that the schema lock is the highest level. It asserts it does not hold either the table lock or the dhandle lock. The table lock is 2nd as its macro asserts that it does not hold the dhandle lock. Then the dhandle lock is last and it does not assert anything about lock state.
