-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Server Programmability
-
ALL
The shutdown of the OpMsgFuzzer has been a persistent source of problems, becuase it currently demands that several objects survive into the static destructor phase, a requirement that never happens in other production or unit test code. It's going to be difficult to keep it working with hacky fixes as these objects and their dependencies evolve. We can avoid this lifespan requirement, though!
The current state of ~OpMsgFuzzerFixture makes a new thread during process shutdown just to run its destructor. It's not clear that it's ok to launch new threads and create decorations etc during process shutdown. Not everything that this code touches is guaranteed to still be valid, and new static duration dependencies can arrive at any time. The idea of having a static duration object simulating a mongod interpreter is technically unsound.
We should invoke Libfuzzer ourselves because we have special shutdown requirements.
https://llvm.org/docs/LibFuzzer.html#using-libfuzzer-as-a-library
That is, we should call this function from a main function that we control.
The OpMsgFuzzerFixture could be local to that main function and have a more conventional lifetime.
extern "C" int LLVMFuzzerRunDriver(int *argc, char ***argv, int (*UserCb)(const uint8_t *Data, size_t Size));
We are using the technique from the intro tutorial of using a static duration fixture, and providing an
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size)
function, which doesn't work well for stateful tests. The problem with this simplified approach is that the fixture never knows when the last call to that function has occurred and it's time to shut down. Our needs are more sophisticated.
- is caused by
-
SERVER-56351 OpMsgFuzzerFixture does not properly shut down the storage engine on destruction
- Closed
-
SERVER-58194 Fix undefined behavior in the destructor for OpMsgFuzzerFixture
- Closed
- is related to
-
SERVER-66385 Remove ThreadName's dependence on ThreadContext (& vice versa apparently)
- Closed