Ich habe in den letzten Wochen daran gearbeitet, einen wirklich schwierigen Bug zu finden, der meine Anwendung zum Absturz bringt. Zuerst stürzte die Anwendung bei der Zuweisung einer std :: string ab, dann während der Freigabe einer lokalen Variablen.
Nach sorgfältiger Prüfung des Codes gab es keinen Grund dafür, dass er an diesen Orten abstürzte; es stürzte jedoch immer ab, während versucht wurde, einen ungültigen Zeiger freizugeben (d. h. einen Zeiger, der auf ungültigen Speicher zeigte). Und ich habe keine Ahnung, warum dieser Zeiger nicht auf den richtigen Ort zeigte.
Ich vermute, dass das Problem mit einem Speicherkorruptionsproblem oder einem Pointer-Korruptionsproblem in irgendeiner Form zu tun hat. Das Problem ist, dass ich es nicht visuell aufspüren kann .... noch. Ich habe keine Ahnung, wo ich anfangen soll, im Code zu suchen, und es gibt Tausende von Codezeilen, die durchlaufen werden müssen, so dass dies nicht als realistische Annäherung an das Problem erscheint.
Also kommt Valgrind ...
Ein Werkzeug, auf das ich oft angewiesen bin, um Probleme im Code zu finden, die zu einem Absturz dieses Typs führen können. Dieses Mal ist es jedoch leer ausgegangen! Ich sehe keine Fehler in Valgrind, wenn das Problem auftritt und daher der Grund für mich, diese Frage zu stellen.
Gibt es weitere Anwendungen, die valgrind ergänzen und dabei helfen können, Probleme im Code zu finden, die den oben genannten Absturz verursachen könnten?
Danke!
Ich nehme an, dass Sie das memcheck-Tool von Valgrind verwenden, für das es berühmt ist. Da Sie valgrind verwenden bereits könnten Sie auch versuchen, Ihr Programm durch valgrind --tool=exp-sgcheck (ehemals exp-ptrcheck Lauf ), die ein experimentelles Werkzeug ist, die bestimmten Arten von Fehlern zu fangen, die memcheck einschließlich Zugriffsüberprüfungen auf ein gültiges Objekt verpassen, konzipierte für Stapel und globale Arrays, und die Verwendung von Zeigern, die Punkt passieren, aber nicht das Objekt, das bestimmt war. Dies geschieht, indem ein völlig anderer Mechanismus verwendet wird, der im Wesentlichen jeden Zeiger in den Speicher verfolgt, anstatt den Speicher selbst zu verfolgen, und durch Verwendung von Heuristiken.
Seien Sie sich bewusst, dass das Werkzeug experimentell ist, aber Sie können feststellen, dass es etwas Bedeutendes fängt. Momentan unterstützt es OS X oder Nicht-Intel-Prozessoren noch nicht.
Meiner Erfahrung nach haben Coverity und Purify solche Fehler verursacht, wie Valgrind es nicht getan hat (tatsächlich haben alle Probleme gefunden, die von den anderen nicht gesehen wurden).
Aber manchmal gibt kein Tool einen Hinweis, und Sie müssen mehr graben, Instrumentierung hinzufügen, mit Breakpoints auf "Speicher bei Adresse ändern" spielen, versuchen, einfach den Testfall zu finden, der fehlschlägt, und so weiter, um die Ursache herauszufinden. Das kann sehr schmerzhaft sein.
Meine Erfahrung ist, dass diese Art von Problemen oft durch einen Heap-Überlauf verursacht wird. Electric Fence ist ein relativ einfaches Tool zum Debuggen von Zuordnungen, das ich gerne benutze. Sein Haupteinsatzgebiet ist ein dynamisches Analysewerkzeug, um nach Heap-Überläufen zu suchen, eine Ergänzung zu "-fstack-protector-all", die nach Stack-Überläufen sucht.
Weitere Links , um Informationen zu erhalten.
Ist es möglich, dass einige Stapel beschädigt sind? Wenn ja, versuchen Sie Stapelkanarien mit dem -fstack-protector-all Option, vorausgesetzt, Sie verwenden g ++.
Haben Sie sonst Warnflags ausgelöst, um verdächtigen Code zu identifizieren?
Meiner Meinung nach könnte es hilfreich sein, einen Debugger mit "reverse debugging" -Funktionen zu verwenden. Sie könnten in der Zeit zurücktreten und hoffentlich herausfinden, was die eigentliche Ursache des Problems war.
Hier sind ein paar Links:
Ссылка (welches anscheinend für nicht-kommerzielle Anwendungen frei ist)
Sie haben die Plattform nicht angegeben, aber ich kann Gimpel PC-Lint als ausgezeichnetes statisches Analysewerkzeug empfehlen (nicht mit dem Namen täuschen!). Sie bieten FlexeLint auch für andere Plattformen an, aber ich habe keine persönliche Erfahrung mit diesem Produkt.
Haben Sie versucht, Lint, Flexlint oder cppcheck zu verwenden? Dies kann helfen, ein Problem zu identifizieren.
Wenn Sie wissen, welcher Speicherbereich beschädigt ist, haben Sie versucht, diesen Speicher als geschützt zu markieren. Dies kann Ihr Problem maskieren und überhaupt nicht helfen, aber wenn der Punkt, an dem der Speicher geändert wird, immer noch abstürzt, hilft das bei der Lösung Ihres Problems.
Wenn valgrind den ungültigen Zeiger identifizieren kann, der an free() übergeben wird, könnten Sie versuchen, das Programm unter DDD auszuführen, wodurch ein Hardware-Watchpoing auf dem Speicherort gesetzt und das Programm gestoppt werden kann, wenn es einen schlechten Wert erhält. Wenn der Zeiger viel geändert wird, müssen Sie möglicherweise etwas Code um malloc schreiben und frei, um zu verfolgen, welche Werte gut und schlecht sind.