MongoRocks tests have been failing for a while with weird errors. I just ran an ASAN test and I think I discovered the root cause. I don't think it's specific to RocksDB storage engine, so I'm surprised that it's not failing in the WiredTiger case.
Here's the stack trace of use-after-free: https://gist.github.com/igorcanadi/76235761eb90f1e1a23b2f35b1627b90
Bear with me:
- Let's start in update.cpp (https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/exec/update.cpp#L867-L868). A call to ensureStillMatches() causes member to point to the invalid buffer.
- ...Because ensureStillMatches() calls into WorkingSetCommon::fetch() with unique_ptr<Cursor> that gets destroyed at the end of the function (https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/exec/write_stage_common.cpp#L53)
- WorkingSetCommon::fetch() sets member->obj to point to the cursor's buffer with function releaseToBson(), which doesn't copy data out of an unowned buffer (https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/exec/working_set_common.cpp#L107)
I believe that the offending commit may be https://github.com/mongodb/mongo/commit/178e241b81882f85a58deda960d80607a77e1c3a (based on 'git blame', I haven't actually bisected it)
Does this make sense?
- is related to
-
SERVER-22178 Should retry a sorted findAndModify if conflicts are detected (non-MMAP only)
- Closed
- related to
-
SERVER-24001 Add a RocksDB+ASan build variant to Evergreen
- Closed