Hi Mr. Derek Bruening!
I originally opened an issue called "Detected Nondeterminism in Dr. Memory between two runs of the same executable under the same configurations." This new issue addresses some of the questions you may have about the determinism of the programs and the determinism of the environment.
I wanted to see the differences between the dynamically linked vs. statically linked FFprobe binary. Additionally, I made another benchmark for testing, where I would also run a reduced version of the FFprobe binary based on the initial stack traces that Dr. Memory generated, where I edited out certain sections of code in the ffprobe binary (this is the second set in each section respectively).
Setup Version of Dr. Memory: Dr. Memory version 2.6.19800 -- build 0
Environment: Barebones Ubuntu 22.04 Server with isolated Docker container
Hardware Specifications: 376GB of RAM and 2 Intel Xeon Gold 5218 16-core CPUs @ 2.30GHz
PrerequisitesDownload the audio file at this Google Drive link:
Audio fileDynamically-Linked VersionThe dynamically linked program is tested deterministic because of the following criterion I took into effect: Does it have the same output, and are the runtime modules loaded the same? I have determined that the output was the same in all 250 runs of the software, and all 250 runs of the software running have the same modules loaded into runtime, which I analyzed using strace.
Dynamically-Linked Executable Reproducible Steps - Original: 1. Clone the repository
https://github.com/FFmpeg/FFmpeg2. Install dependencies: nasm and yasm
3. Go into the cloned directory and enter "./configure --enable-shared --disable-static && make -j$(nproc)"
4. Run for 250 times: drmemory -logdir "<your directory here>" ./ffprobe sanic.mp3
5. Diff each Dr. Memory run sequentially
Dynamically-Linked Executable Reproducible Steps - Reduced: 1. Clone the repository
https://github.com/joalen/FFmpeg2. Install dependencies: nasm and yasm
3. Go into the cloned directory and enter "./configure --enable-shared --disable-static && make -j$(nproc)"
4. Run for 250 times: drmemory -logdir "<your directory here>" ./ffprobe sanic.mp3
5. Diff each Dr. Memory run sequentially
Observations:
The original FFprobe program reported two uninitialized reads in one run and no errors in the other. This is the case in 30/250 Dr. Memory report pairs.
The reduced binary reported not only kept the two uninitialized reads but also added a memory leak error in one run and no errors in the other run. This is the case for 16/250 Dr. Memory report pairs.
Statically-Linked VersionIn the statically linked version, the outputs remained the same in all 250 runs and in addition, running ldd on the FFprobe static binary reported "not a dynamic executable." I also ran the file command, which says "ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked for GNU/Linux 3.2.0, stripped"
Statically-Linked Executable Reproducible Steps - Original:
1. Clone the repository
https://github.com/FFmpeg/FFmpeg2. Install dependencies: nasm and yasm
3. Go into the cloned directory and enter "--enable-static --disable-shared --extra-libs=-static --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" --pkg-config-flags="--static && make -j$(nproc)"
4. Run for 250 times drmemory -logdir "<your directory here>" ./ffprobe sanic.mp3
5. Diff each Dr. Memory run sequentially
Statically-Linked Executable Reproducible Steps - Reduced: 1. Clone the repository
https://github.com/joalen/FFmpeg2. Install dependencies: nasm and yasm
3. Go into the cloned directory and enter "--enable-static --disable-shared --extra-libs=-static --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" --pkg-config-flags="--static && make -j$(nproc)"
4. Run for 250 times drmemory -logdir "<your directory here>" ./ffprobe sanic.mp3
5. Diff each Dr. Memory run sequentially
Observations:
The original FFprobe program reported multiple errors about "UNADDRESSABLE ACCESS beyond heap bounds" for reading and writing operations. This turns out to be the case in 6/250 Dr. Memory report pairs.
The reduced binary reported kept the same "UNADDRESSABLE ACCESS beyond heap bounds" for both the reading and writing operations. This turns out to be the case in 4/250 Dr. Memory report pairs.
More observations:
Additionally, when running Dr. Memory on that FFprobe binary, this error stack shows up:

Would you mind taking a look at the Dr. Memory program and provide insights into the Dr. Memory tool for the above observations?
Thank you very much!