Currently Python testing flow for TSan looks by the following way:

• Configure WT with `-DCMAKE_BUILD_TYPE=TSan` option
• Compile WT
• Set TESTUTIL_TSAN env variable
• Run run.py

If TESTUTIL_TSAN is set, run.py will search for path to libtsan.so and set it to LD_PRELOAD before running the tests because WT library requires TSan symbols but doesn't contain explicit dependency on libtsan.so. Instead of this it seems like all these symbols are statically linked in C/C++ tests executables. So since we don't have these executables with symbols for Python testing we need to set LD_PRELOAD to load them from libtsan.so.

Generally it looks fine, but I didn't find any information why does TSan has this pretty strange design and whether this way of testing is the right one in our case. Also, currently we search for path to `libtsan.so` using `clang --print-file-name` tool which can be tricky in case of having several TSan instances on a system (see TSan related notes inside this ticket https://jira.mongodb.org/browse/WT-14298). Also worth noting that in case of setting LD_PRELOAD we do python reload operation (like replacing this process by new one for noticing all the variables) and this operation can silently enter to some very weird state if LD_PRELOAD was set to wrong ASAN version.

That's why I created a github issue for sanitizers project to ask TSan developers what is the right way to use TSan in our case: https://github.com/google/sanitizers/issues/1856

So FMPOV it worth investigation whether we use TSan for python testing by the right and most convenient way. I would like to raise the following questions:

• Is setting LD_PRELOAD a correct way for python testing?
  • If yes, is there better way to precisely detect path to correct libtsan.so version?
• Can we automatically detect TSan testing case and avoid requirement to set TESTUTIL_TSAN env variable?