-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Checkpoints, Logging
-
None
-
Environment:GCC 13, Ubuntu 24.04
-
Storage Engines - Persistence
-
0
-
None
-
1
In src/txn/txn_log.c _wt_checkpoint_log (line 436), if a failure occurs during checkpoint logging stages (such as WT_TXN_LOG_CKPT_START or WT_TXN_LOG_CKPT_STOP), control jumps to the err: label (line 568). This jump bypasses the WT_TXN_LOG_CKPT_CLEANUP block, leaving txn->full_ckpt stuck as true and leaking the allocated txn->ckpt_snapshot scratch buffer. Consequently, subsequent non-full checkpoint or file-sync logging calls will silently short-circuit and return 0, compromising durability guarantees. Additionally, the leaked scratch buffer remains marked as in-use, causing a memory leak.
For Reproduce;
A catch2 unit test (test_checkpoint_log_cleanup.cpp) reproduces the bug and verifies the fix (I attached the before/after outputs on JIRA).
Without the fix, txn->full_ckpt remains true after a checkpoint logging failure, causing subsequent non-full checkpoint and file-sync logging calls to silently short-circuit and return 0, while the ckpt_snapshot scratch buffer leaks.
With the fix, full_ckpt is correctly reset and the scratch buffer is released on error.
Proposed Fix;
Adding cleanup under the err: label of __wt_checkpoint_log(). When full is true and ret is non-zero, reset txn->full_ckpt to false and free the ckpt_snapshot scratch buffer, consistent with the existing cleanup logic in WT_TXN_LOG_CKPT_CLEANUP.