Discussions with martin.bligh and michael.cahill about the fact that WT_CURSOR.insert is slightly different from other cursor operations because it requires applications keep application memory referenced via the set-key and set-value methods valid over multiple cursor calls. This is a side-effect of the fact that WT_CURSOR.insert doesn't "position" the cursor, which is the action that changes the cursor to reference in-database key/value memory, rather than application key/value memory.

This potentially leads to a core dump in this sequence:

WT_CURSOR.set_key
WT_CURSOR.set_value
WT_CURSOR.insert
free set-key memory
WT_CURSOR.search

It's a wildly unlikely application pattern, but still an odd corner case.

Decision was to change WT_CURSOR.insert to unset the key/value after the insert, so the update in the above example would fail naturally because there's no key/value set.