Valgrind run of test_base05.test_base05.test_table_ss complains:
python ../test/suite/run.py test_base05.test_base05.test_table_ss ==28947== Source and destination overlap in memcpy(0x11c63000, 0x11c63028, 255) ==28947== at 0x4A08B8E: memcpy (mc_replace_strmem.c:882) ==28947== by 0xCFC23E1: __wt_buf_set (scratch.c:130) ==28947== by 0xCF2872D: __cursor_row_slot_return (cursor.i:244) ==28947== by 0xCF29C2C: __cursor_row_next (bt_curnext.c:308) ==28947== by 0xCF29FD5: __wt_btcur_next (bt_curnext.c:434) ==28947== by 0xCF79A3C: __curfile_next (cur_file.c:87) ==28947== by 0xCCF5FE4: _wrap_Cursor_next (wiredtiger_wrap.c:3680)
I don't see any reason we should not change *wt_buf_set to use memmove, it's not reasonable to use *wt_buf_set to shuffle strings around?
What's a little scary (and why I'm creating this issue), is the comment in __cursor_row_slot_return:
/* * If we previously built a prefix-compressed key in the * temporary buffer, the WT_ITEM->data field will be the * same as the WT_ITEM->mem field. If we previously * pointed the temporary buffer at an on-page key, the * WT_ITEM->data field will not be the same as the * WT_ITEM->mem field: first copy the prefix into place. * * Care is required: the WT_ITEM_MAPPED flag may be set * if this is a memory-mapped file, so it is important * to copy the data before growing the buffer. */ if (cbt->tmp.data != cbt->tmp.mem) WT_RET(__wt_buf_set(session, &cbt->tmp, cbt->tmp.data, unpack->prefix));
That comment makes me think this shouldn't ever happen, that either cbt->data and cbt->mem are the same, or cbt->data points on-page, so there shouldn't be any overlap.