Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Done
-
None
-
None
-
None
Description
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.
Attachments
Issue Links
- 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
-