-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
5
-
Storage Engines - 2023-01-10
Through testing backup cursors, I have come across a bug in the case where a backup cursor, and a duplicate backup cursor is opened, and closing the backup cursor before the duplicate backup cursor is closed. In this case we hit an assert
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff7a22921 in __GI_abort () at abort.c:79 #2 0x00007ffff5075219 in __wt_abort (session=session@entry=0xd580f0) at ../src/os_common/os_abort.c:30 #3 0x00007ffff505e21e in __backup_stop (cb=0xf62f20, session=0xd580f0) at ../src/cursor/cur_backup.c:843 #4 __curbackup_close (cursor=0xf62f20) at ../src/cursor/cur_backup.c:238 #5 0x00007ffff553f976 in _wrap_Cursor_close (self=<optimized out>, args=<optimized out>) at lang/python/wiredtigerPYTHON_wrap.c:4672 #6 0x0000000000566f45 in PyCFunction_Call () #7 0x0000000000510f56 in _PyEval_EvalFrameDefault () #8 0x0000000000507cd4 in ?? () #9 0x0000000000509a00 in ?? ()
The assert hit is
/* If it's not a dup backup cursor, make sure one isn't open. */
WT_ASSERT(session, !F_ISSET(session, WT_SESSION_BACKUP_DUP));
Definition of done
Instead of hitting an assert, we should return an error saying that we can't close the backup cursor and place a message to denote that we can't close the backup cursor until all the duplicate cursors are closed.
Also create a python test that validates this behaviour.