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


Anmelden zum Antworten