-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
None
-
None
I just saw a core dump in format that concerns me, I've attached the CONFIG.
Some caveats: this was in the wt-2182-split-race, with various edits, so this may not be real. I've also been running this particular CONFIG for most of a week, and this is the first time I've seen this trigger, so feel free to discard this ticket, it may not be worth chasing.
Here's the information:
#0 0x00000000004de394 in __sync_file (session=0x80351ea00, syncop=1)
at src/btree/bt_sync.c:155
#1 0x00000000004dde81 in __wt_cache_op (session=0x80351ea00,
ckptbase=0x80cd49c00, op=1) at src/btree/bt_sync.c:277
#2 0x00000000004a1de5 in __checkpoint_worker (session=0x80351ea00,
cfg=0x7ffffddeedc0, is_checkpoint=true, need_tracking=true)
at src/txn/txn_ckpt.c:1100
#3 0x00000000004a0f3e in __wt_checkpoint (session=0x80351ea00,
cfg=0x7ffffddeedc0) at src/txn/txn_ckpt.c:1191
#4 0x00000000004a35cc in __checkpoint_apply (session=0x80351ea00,
cfg=0x7ffffddeedc0, op=0x4a0e80 <__wt_checkpoint>)
at src/txn/txn_ckpt.c:184
#5 0x00000000004a065d in __txn_checkpoint (session=0x80351ea00,
cfg=0x7ffffddeedc0) at src/txn/txn_ckpt.c:507
#6 0x000000000049f893 in __wt_txn_checkpoint (session=0x80351ea00,
cfg=0x7ffffddeedc0) at src/txn/txn_ckpt.c:668
#7 0x000000000048b921 in __session_checkpoint (wt_session=0x80351ea00,
config=0x0) at src/session/session_api.c:1067
#8 0x0000000000408334 in ops (arg=0x80347cdc0) at ops.c:367
(gdb) l
151 * Mark the tree dirty: the checkpoint marked it clean
152 * and we can't skip future checkpoints until this page
153 * is written.
154 */
155 if (!WT_PAGE_IS_INTERNAL(page) &&
156 F_ISSET(txn, WT_TXN_HAS_SNAPSHOT) &&
157 WT_TXNID_LT(txn->snap_max, mod->first_dirty_txn)) {
158 __wt_page_modify_set(session, page);
159 continue;
(gdb) p page->type
$6 = 4 '\004'
(gdb) p/x txn->flags
$7 = 0x4c
(gdb) p mod
$8 = (WT_PAGE_MODIFY *) 0x0
(gdb) p page->modify
$9 = (WT_PAGE_MODIFY *) 0x8101c3740
(gdb) p txn->snap_max
$10 = 880303
(gdb) p page->modify->first_dirty_txn
$11 = 882711
(gdb) l 131,137
131 page = walk->page;
132 mod = page->modify;
133
134 /* Skip clean pages. */
135 if (!__wt_page_is_modified(page))
136 continue;
So, what happened is we took a copy of page->modify, and then called __wt_page_is_modified, and between those instructions, the page was modified.
Obviously, we could take the copy of page->modify after calling __wt_page_is_modified, but I wanted to be sure nothing else is going on.
- is depended on by
-
SERVER-21349 WiredTiger changes for 3.2.0-rc3
-
- Closed
-
- related to
-
WT-5650 Fix a race condition between reading the WT_PAGE.modify field and the page being dirtied.
-
- Closed
-