I was running changeset b4551f65a289ffe8e17d0b075958a9a00da940e3 with the voxer-10k-short config for wtperf to try and reproduce the checksum failure seen. It ran a few hundred iterations overnight. I periodically got these messages:

[1399379418:141237][30451:00c77ffa9f7f0000], session.close: scratch buffer allocated and never discarded: ../src/lsm/lsm_cursor.c: 210

The allocation is in *clsm_deleted_encode and I looked at the only two callers. They are *clsm_insert and _clsm_update. I do not see any path after that call out of either function without calling _wt_scr_free. Perhaps there is a race or wtperf is closing while a cursor is active.