-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Checkpoints
-
None
-
Environment:GCC 13, Ubuntu 24.04
-
Storage Engines - Persistence
-
225.307
-
StorEng - Defined Pipeline
-
1
-
v9.0, v8.3, v8.0
In __checkpoint_db_internal (checkpoint_txn.c), F_SET(session, WT_SESSION_CHECKPOINT) is called at line 1729 before __checkpoint_apply_operation validates the checkpoint name. When validation rejects a reserved name (e.g. "all" or any WiredTigerCheckpoint* prefix), the function returns immediately via WT_RET without reaching __checkpoint_teardown, leaving WT_SESSION_CHECKPOINT permanently set on the user session and checkpoint_state stuck at WTI_CHECKPOINT_STATE_ESTABLISH. On the next commit_transaction on that session, __wt_txn_commit (txn.c line 966) asserts txn_shared_list[session->id]->id == WT_TXN_NONE and an assertion that fires because the session carries a real write transaction id while the checkpoint branch expects WT_TXN_NONE and causing SIGABRT in diagnostic builds and silent checkpoint_id corruption in release builds. A second early-exit path has the same stat leak, the can_skip return at line 1726 and increments checkpoint_skipped but does not reset checkpoint_state to INACTIVE.
For Reproduce;
A Catch2 unit test (test_checkpoint_session_flag.cpp) reproduces both failure modes and verifies the fix (I added before/after outputs added on JIRA).
In a scenario, a user session calls WT_SESSION::checkpoint with name=all (a reserved name). __checkpoint_apply_operation returns EINVAL, but WT_SESSION_CHECKPOINT is already set. CHECK_FALSE(F_ISSET(session, WT_SESSION_CHECKPOINT)) fails and the flag is still set. A subsequent begin_transaction + commit_transaction on the same session then hits the assertion in __wt_txn_commit (txn.c line 966): txn_shared_list[session->id]->id == WT_TXN_NONE evaluates false because the session now holds a real write-transaction id, causing SIGABRT.
With the fix, F_SET(session, WT_SESSION_CHECKPOINT) is deferred until after __checkpoint_apply_operation succeeds, CHECK_FALSE passes, and the subsequent commit completes without aborting.
Proposed Fix;
Move F_SET(session, WT_SESSION_CHECKPOINT) to after __checkpoint_apply_operation succeeds and reset checkpoint_state to WTI_CHECKPOINT_STATE_INACTIVE on both early-exit paths.