Ergänzung zu Valgrind?

Question

Ich habe in den letzten Wochen damit gearbeitet, einen wirklich schwierigen Bug zu finden, der meine Anwendung stürzt. Zuerst stürzte die Anwendung auf die Zuweisung einer std :: string, dann während der Freigabe einer lokalen Variablen ab.

Nach sorgfältiger Prüfung des Codes gab es keinen Grund für einen Absturz an diesen Stellen; 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 Speicherbeschädigungs-Problem oder Pointer-Korruptions-Problem irgendeiner Art 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.

So kommt Valgrind ...

Ein Werkzeug, das ich über viele eine Zeit abhing haben Probleme im Code zu finden, die zu einem Absturz dieser Art führen kann. 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 noch andere Anwendungen, die Valgrind ergänzen und dabei helfen können, Probleme im Code zu finden, die den oben erwähnten Absturz verursachen könnten?

Vielen Dank!

Answer 1

Haben Sie versucht, mit Lint, Flexlint oder cppcheck. 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 dies, Ihr Problem zu lösen.

Answer 2

Meiner Erfahrung nach haben Coverity und Purify solche Fehler verursacht, die Valgrind nicht hatte (alle fanden Probleme, die von den anderen nicht gesehen wurden).

Aber manchmal gibt kein Werkzeug einen Hinweis, und Sie müssen mehr graben, Instrumentierung hinzufügen, mit Breakpoints auf "Speicher bei Adresse ändern" spielen, versuchen Sie einfach den Testfall, der fehlschlägt und so weiter, um die Ursache herauszufinden. Das kann sehr schmerzhaft sein.

Answer 3

Sie haben die Plattform nicht angegeben, aber ich kann Gimpel PC-lint als ein ausgezeichnetes statisches Analysewerkzeug empfehlen (lassen Sie sich nicht durch den Namen täuschen!). Sie bieten FlexeLint auch für andere Plattformen an, aber ich habe keine persönliche Erfahrung mit diesem Produkt.

Answer 4

Ich nehme an, Sie verwenden Valmind memcheck Werkzeug, für das es berühmt ist. Da Sie Valgrind bereits verwenden, können Sie auch versuchen, Ihr Programm über valgrind --tool=exp-sgcheck (früher exp-ptrcheck) auszuführen, was ein experimentelles Tool ist, das bestimmte Arten von Fehlern abfangen kann, die mecheck verpassen wird, einschließlich Zugriffsprüfungen für Stack- und globale Arrays von Zeigern, die auf ein gültiges Objekt, aber nicht auf das beabsichtigte Objekt zeigen. Dies geschieht durch Verwendung eines völlig anderen Mechanismus, wobei im Prinzip jeder Zeiger in den Speicher verfolgt wird, anstatt den Speicher selbst zu verfolgen, und indem Heuristiken verwendet werden.

Beachten Sie, dass das Tool 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.

Answer 5

Ist es möglich, dass einige Stapelfehler auftreten? Ist dies der Fall, versuchen Sie, stack canaries mit der Option -fstack-protector-all zu aktivieren, vorausgesetzt, Sie verwenden g ++.

Hast du sonst Warnflags aktiviert, um verdächtigen Code zu identifizieren?

Answer 6

Wenn Valgrind den ungültigen Zeiger identifizieren kann, der an free() übergeben wird, können Sie versuchen, das Programm unter DDD auszuführen, das eine Hardwareüberwachung auf dem Speicherort festlegen und das Programm anhalten kann, wenn es einen ungültigen 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.

Answer 7

Meine Erfahrung ist, dass diese Art von Problem oft durch einen Heap-Überlauf verursacht wird. Electric Fence ist ein relativ einfaches Zuordnungs-Debugging-Tool, das ich gerne benutze. Es wird hauptsächlich als dynamisches Analysewerkzeug verwendet, um nach Heap-Überläufen zu suchen, eine Ergänzung zu "-fstack-protector-all", die nach Stack-Überläufen sucht.

More links zu efence Zeug.

Answer 8

Meiner Meinung nach könnte die Verwendung eines Debuggers mit "Reverse-Debugging" -Fähigkeiten helfen. Sie könnten in der Zeit zurücktreten und hoffentlich herausfinden, was die eigentliche Ursache des Problems war.

Hier sind ein paar Links:

http://www.gnu.org/software/gdb/news/reversible.html

http://undo-software.com/ (die offenbar frei für nicht-kommerzielle Anwendungen sind)