Cursor iteration can fail to yield keys added in an order opposite to the cursor's iteration order. If the cursor iterating forwards at "3", and "6" then "5" are added, "5" will never be hit. Would fail to suppress many deleted keys, but this is hidden by logic that issues a get() against the transaction on every continue() call.
Created attachment 138131 [details] Patch
Comment on attachment 138131 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=138131&action=review > Source/WebCore/platform/leveldb/LevelDBTransaction.cpp:417 > + && (!m_dbIterator->isValid() I find the logic of this very difficult to read - can you break at least the direction checks into a separate helper function? these: || (m_direction == kForward && m_comparator->compare(m_treeIterator->key(), m_dbIterator->key()) < 0) || (m_direction == kReverse && m_comparator->compare(m_treeIterator->key(), m_dbIterator->key()) > 0))
Created attachment 138445 [details] Patch
Comment on attachment 138445 [details] Patch Thanks, this makes it much clearer...you can make the helpers const too. LGTM with that.
Created attachment 138452 [details] Patch
LGTM. ojan@ - can you review?
Comment on attachment 138452 [details] Patch Clearing flags on attachment: 138452 Committed r115260: <http://trac.webkit.org/changeset/115260>
All reviewed patches have been landed. Closing bug.
Committed r115275: <http://trac.webkit.org/changeset/115275>
Fix was reverted due to failures in debug build.
Created attachment 138926 [details] Patch
Comment on attachment 138926 [details] Patch ojan@ - can you review again? I had to remove a stale assert.
Comment on attachment 138926 [details] Patch Clearing flags on attachment: 138926 Committed r115333: <http://trac.webkit.org/changeset/115333>