Details
Description
The elemMatchProjection.js integration test has various assertions which sort by _id, and depend on this sort enforcing a particular ordering. The test, however, does not supply explicit _id values. It instead relies on the shell generating ObjectIds, and it assumes that these ObjectIds are monotically increasing.
This is not a sound assumption. As documented here, the least significant three bytes of an ObjectId consist of an incrementing counter which is seeded with a random value. If the uint32_t seed is close to 0xffffffff, then during the execution of the test, the counter will roll over to zero. If this occurs, the sort order of the _id values will not match the shell's insertion order, causing the test to fail.
The test fails consistently after building the server with the following patch:
diff --git a/src/mongo/bson/oid.cpp b/src/mongo/bson/oid.cpp
|
index 26d90d97ba..00f0159f1d 100644
|
--- a/src/mongo/bson/oid.cpp
|
+++ b/src/mongo/bson/oid.cpp
|
@@ -54,7 +54,7 @@ OID::InstanceUnique _instanceUnique;
|
MONGO_INITIALIZER_GENERAL(OIDGeneration, MONGO_NO_PREREQUISITES, ("default"))
|
(InitializerContext* context) {
|
std::unique_ptr<SecureRandom> entropy(SecureRandom::create());
|
- counter.reset(new AtomicUInt32(uint32_t(entropy->nextInt64())));
|
+ counter.reset(new AtomicUInt32(uint32_t(0xffffff35)));
|
_instanceUnique = OID::InstanceUnique::generate(*entropy);
|
return Status::OK();
|
}
|
This replaces random seeding of the ObjectId counter with a hardcoded value of 0xffffff35, designed to demonstrate the problem.