Hallo, ich habe eine mittlerweile doch recht komplexe VC++ Anwendung, die mehrere Workerthreads nutzt, die sich gegenseitig benötigen. Mit der Zeit hat sich irgendwo ein richtig fieser Bug eingeschlichen, den ich aber nicht gleich bemerkt habe. Die Frage ist nur WO! Der Bug ist nicht provozierbar und tritt irgendwann mal auf. Sowohl beim Debuggen der Anwendung, als auch beim fertigen Release. Mal alle 10 Minuten, mal nur einmal die Woche. Er äußert sich so, dass der PC komplett ausgelastet wird, wenn man z.B. einen Breakpoint erreicht, oder die Software mal vom Debugger aus "abschießt" (STOP-Button drückt). Manchmal passiert das auch "einfach so" während dem Programmfluss ohne erkennbares Zutun. Irgendwas ist hier im Thread-Handling nicht sauber und verklemmt sich saumäßig, ich vermute irgendeine Endlosschleife, da die Prozessorlast auf 100% steigt trotz Dual-Core ;-) Das Problem ist nur: Wenn der Bug aufgetreten ist, ist es auch schon zu spät, denn der PC ist dann nicht mehr bedienbar, allein der Task-Manager braucht 10 Minuten um angezeigt zu werden. Allerdings ist Software die schon offen ist, noch einigermaßen bedienbar (außer Visual Studio selbst!). Jetzt meine Frage: Gibt es ein Tool, das Prozesse überwacht und anzeigt was die so an Ressourcen (Speicher, CPU) verbrauchen, sowie deren Threads anzeigen und welche davon wieviel CPU-Zeit benötigen oder was die grade machen (SUSPENDED, READY, RUNNING, etc.)? Vielleicht würde ich so eher auf die Schliche kommen, was hier faul ist. Kennt ihr da was?
wenn die CPU so ausgelastet ist, dann muss es ja eine sehr kleine Schleife sein in welcher sich die Threads befinden. Da sollte doch zu finden sein. Wenn man im Debugger auf Pause drückt, dann halte doch alle Threads an, da kann man doch nachschauen wo sie sind. Wenn du eine MultiCore CPU hast, dann kannst du der Anwendung nur eine CPU zuweisen, damit hast du die andere(n) zum Debuggen frei.
Solche Tools gibt es z.B. ProcMon http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx Schlauer wäre es eine Überwachung und Debugausgabe in dein Programm zu pflanzen, die du z.B. über Debugview anzeigen und aufzeichnen und auswerten kannst (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) Noch schlauer wäre es den Quellcode bzw. das Programm selbst unter die Lupe zu nehmen z.B. mit einem Threads Checker (Intel: http://software.intel.com/en-us/intel-thread-checker/) oder Memory Checker (http://en.wikipedia.org/wiki/BoundsChecker)
Peter schrieb: > Wenn du eine MultiCore CPU hast, dann kannst du der Anwendung nur eine > CPU zuweisen, damit hast du die andere(n) zum Debuggen frei. Und u.U. eine fehlerfrei laufende Anwendung... Anderes empfehlenswertes Tool: http://research.microsoft.com/en-us/projects/chess/ http://research.microsoft.com/en-us/projects/chess/doc.aspx Ansonsten könnte man auch noch mit Hilfe der Performance Counter, die entsprechenden Threads überwachen.
Eine verdächtige while-Schleife hab ich schonmal gefunden, aber ob es die war, kann ich erst in ein paar Tagen sagen, denn nichts genaues weiß man ja nich ... :) Vielen Dank schonmal für die Links, die werde ich mir morgen im Büro mal ansehen, vom Namen her klingen die aber schonmal vielversprechend! Wie kann man denn im Visual Studio einstellen, dass der ausgeführte Code nur auf einem Core läuft? Ich habe da in den Projekteinstellungen nichts finden können? Oder gibt es da ganz allgemeine Tools, wo man in den Windows-Scheduler diesbezüglich eingreifen kann?
einfach ein Taskmanager auf dem Prozess gehen und Rechte maustaste -> Zugehörigkeit festlegen
Tja, da hat wohl jemand den Wald vor lauter Bäumen nicht gesehen. Danke!
Peter schrieb: > einfach ein Taskmanager auf dem Prozess gehen und Rechte maustaste -> > Zugehörigkeit festlegen oder über die Kommandozeile: start /affinity x
Vielen Dank für die Tool-Tipps. Ich hab mir noch ein paar andere SysInternals angesehen und einen Bug tatsächlich gefunden: Die RS232 wird von einem Thread bedient und es gab eine kurze Codepassage, die nicht gesichert war. Genau dort hat irgendein anderes Programm auf meinem PC (dem ich das inzwischen verboten habe) sich diesen RS232-Port geschnappt und damit durch eine ungeschickte while-Bedingung ne Endlosschleife in dem Thread provoziert.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.