Erfahrung mit Threading/Speicher, Problem Findung/Stresstests

Ich hatte vor ein paar Tagen schon mal einen ähnlichen Post erstellt, der war aber nicht ganz konform zu den Forums-Regeln also habe ich den Post nochmal neu formuliert und hoffe bei diesem hier auf interessantens Feedback

Es geht mir primär um C/C++ Software (wobei ich auch schon in Delphi oder Java, C# Schnittstellen hin zu C Fehler dieser Art finden musste)
-die ein bisschen oder viel asynchrone Berechnungen oder IO-Behandlungen enthält (z.B. Kommunikation zu Maschinen/Servern usw.)
-meist als Daemon oder Service/Process ohne GUIs
-kleine Libs mit schöner API oder komplette Programme mit allem im Bauch ohne starke modulare Trennung
-die schon älter, fertig oder am Ende ihrer Entwicklung steht - (meist >500-800kLOC) = ich kann da auch nicht leichtens was Umbauen oder mal schnell Tests extrahieren
-die teilweise nicht unter Linux/GCC läuft/kompiliert also nicht mit den Sanitizern oder Valgrind getestet werden können
-zu groß oder schwer zerlegbar sind um so einfach durch den Intel Inspector und Konsorten gejagt zu werden (Testlauf wird viel zu lang oder verlangsamt zu sehr)
-meistens nicht von mir entwickelt wurden

Worum es mir geht:
-ich will weitere Hilfsmitteln/Strategien kennen lernen um Fehler zu entdecken
-Szenario-Findung für schwer reproduzierbare - also eher stochern im trüben Wasser, pseudo hardening

Worum es mir absolut nicht geht:
-Effektivere Ausnutzung von Parallelisierung oder bessere Skalierung über mehr CPUs/Kerne/Threads oder Prozesse oder die leichtere Programmierung davon
-Ich habe kein akutes Problem das ich zu lösen versuche - finden und lösen kann ich, aber geht es noch besser/schneller?

Hilfsmittel/Strategien die ich schon nutze:
-statischen Analyse-Tools with cppcheck, PVS-Studio, VS-Analyzer, Warning-Level, clang-tidy, Coverity, CodeSonar... - die freien immer, die kommerziellen soweit beim Kunden verfügbar
-dynamische Analyse-Tools: Sanitizer, Valgrind, Kompiler-Features
-unterschiedliche Kompiler, Platformen, Betriebssysteme und Standardlibs sind auch sehr schön um Fehler zu finden
-bei 32Bit auf 64Bit portierung die Applikation zwangsweise über der 4GB-Grenze in den Speicher zu laden - um schneller fiese Pointer-Cast Fehler zu finden

Praxiserfahrungen:

wenn ich Software die primär unter 32Bit getestet wird unter 64Bit laufen lasse finde ich mehr latente Speicher/Threading Fehler (auf gleicher Hardware, gleiche Testszenarien)
mir ist noch unklar ob das primär durch die andere Codegenerierung, mehr Speicherbewegung durch fettere Pointer, langsamere/schnellere Codeausführung usw. verursacht wird - wahrscheinlich
von allem ein bisschen

bei Threading habe ich z.B. die Erfahrung gemacht das ich mehr Fehler finde wenn man die Software auf langsamen/schnellen, wenig/viele Kernen Systemen mit den Testszenarien stresst
Ich hatte mal eine Software die nur auf einem alten SingleCore-System in kurzen Abständen Deadlocks hatte, auf keinem Multi-Core System ist in Stresstests (die über Tage gelaufen sind)
dieser Fehler aufgetreten

hat von euch jemand auch solche Erfahrungen oder kann Tips geben: Ein Tip war schon mal das man bei MultiCore-Systemen
Kerne auch gezielt abschalten kann, z.B. im BIOS um ein SingleCore System zu erhalten

vielleicht gibt es ja ein paar Leute die ein bisschen aus dem Nähkästchen plaudern wollen