This ticket is the result of a Replication Team meeting where we considered what costs us time debugging Evergreen test failures. One time-consuming scenario is when a flaky test fails, giving us a core dump and stack trace, but only on an optimized build. This could happen because the debug build has different timings, or just bad luck.

The stack trace for an optimized build omits some parameters:

0x0000564b0908f502 in mongo::Lock::GlobalLock::GlobalLock (this=0x7fb704ea45f8, opCtx=<optimized out>, lockMode=<optimized out>, deadline=..., behavior=<optimized out>) at src/mongo/db/concurrency/d_concurrency.cpp:139

And when we load the core dump in GDB, many local variables and parameters are inaccessible.

Obviously, a release build must be less debuggable than a debug build, but is there anything we can do to get better stack traces and more informative core dumps from release builds than we do today, without making the binary bigger or slower?