-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Cursors, Test Python
-
Storage Engines - Foundations
-
None
-
5
-
20
Python tests call WT_CURSOR::close repeatedly, if the call return EBUSY. However, sometimes the underlying cursor object deletes itself, and then returns EBUSY, leaving the python side with a dangling pointer.
Investigation:
- __curfile_close frees the cursor prematurely.
- After it calls __wt_cursor_close, it attempts to release dhandle via __wt_session_release_dhandle, which may return EBUSY.
- The EBUSY error then propagated all the way to the WT_CURSOR::close caller. The caller is in the Python test_ovfl01.
- On subsequent call to WT_CURSOR::close, the underlying cursor is already freed. The Python code holds a garbage pointer at this point and segmentation fault occurs.
In addition, the first call to __wti_cursor_cache_release does not check the return value.
To reproduce the problem, run the following shell command (from build directory):
for i in {1..1000}; do echo "[Round $i]"; python3 ../test/suite/run.py test_ovfl01 -v 2 || break; done
Solution:
- Check if cursor is busy. If yes, return EBUSY without destroying internal state.
- Otherwise, proceed as normal.
- is duplicated by
-
WT-16393 failed: spinlock-pthread-adaptive-test on amazon2023-release-armv9 [wiredtiger @ a0b7216e]
-
- Closed
-
-
WT-16415 failed: unit-test-bucket06 on ubuntu2004-asan [wiredtiger @ c5ac8671]
-
- Closed
-
- is related to
-
WT-5521 Cache stuck during format initial load, configured with library checkpoints
-
- Closed
-
-
WT-15739 Fix reconciliation leaking overflow pages
-
- Closed
-
- related to
-
WT-15849 test_ovfl01 TypeError: in method 'Cursor__freecb', argument 1 of type 'struct __wt_cursor *'
-
- Closed
-