Praktische Weitergabe der Linux-Entwicklungs-Coredump-Dateianalyse

Vorwort:

In der Embedded-Linux-Entwicklung ist die Analyse von Coredump-Dateien eine gängige Methode, und im Internet finden wir häufig entsprechende Tutorials zur Verwendung. Es gibt jedoch nur wenige Artikel zur Analyse von Coredump-Dateien von Multithread-Anwendungen. Heute werde ich einige Fälle vorstellen, auf die ich im tatsächlichen Gebrauch gestoßen bin, in der Hoffnung, allen etwas Hilfe zu bieten. Aufgrund von Code- und Platzbeschränkungen werde ich nur die Probleme beschreiben, die meiner Meinung nach ausgeprägter sind, und Framework-Denken verwenden, um viele aufgetretene Coredump-Dateisituationen zu lösen.

Autor: Das Gewissen existiert noch

Nachdruckgenehmigung und Zuschauer: Willkommen, um dem öffentlichen WeChat-Konto zu folgen: Hamebayashi-kun

Oder fügen Sie den persönlichen WeChat des Autors hinzu: become_me

---

Ploteinführung:

Beim Debuggen einer Funktion habe ich einige Coredump-Dateien generiert und es sind verschiedene Programmfehler aufgetreten. Bei dieser Gelegenheit möchte ich es mit allen teilen. Im Allgemeinen können Coredump-Dateien aufgrund von Nullzeigern, außerhalb der Grenzen liegenden Arrays, mehreren Freigaben durch mehrere Threads, Stapelüberlauf usw. generiert werden. Hier habe ich einige repräsentative Probleme basierend auf den Situationen, denen ich begegnet bin, ausgewählt und teile mit Ihnen einige einfache Lösungen.

Um entsprechend zu debuggen, müssen wir zunächst das GDB-Tool verwenden. Bevor Sie mit der Analyse der Coredump-Datei beginnen, müssen Sie mit den verschiedenen Befehlen von gdb vertraut sein. Unten sind zwei Artikel, die ich zuvor über das GDB-Debugging geschrieben habe:

Ein Artikel für den Einstieg in das GDB-Debugging unter Linux (1)

Ein Artikel für den Einstieg in das GDB-Debugging unter Linux (2)

Daher geht dieser Artikel nicht näher auf diese Inhalte ein, sondern konzentriert sich nur auf die tatsächlichen Vorgänge, die wir bei der Analyse von Coredump-Dateien ausführen müssen.

Zuerst müssen wir das Debuggen mithilfe einer ausführbaren Datei mit Debugging-Informationen durchführen.

gdb executable_file coredump_file

Beispiel 1: Zeigerinitialisierung fehlgeschlagen

Nach der Eingabe müssen Sie zunächst den Befehl bt verwenden, um die Stapelinformationen anzuzeigen

In dieser Coredump-Datei können wir leicht erkennen, dass es einen deutlichen Datenunterschied zwischen der eingehenden Adresse einer Funktion und der Klassenmitgliedsfunktion gibt. Wir können zu einem so offensichtlichen Teil direkt eine Schlussfolgerung ziehen und dann die Details überprüfen.

f  n 

Wählen Sie Frames nach Frame-Nummer aus. Die Frame-Nummer kann über den BT-Befehl angezeigt werden.

我们查看对应的第 17帧的堆栈信息

通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。

为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息

然后我们需要确认该指针是什么什么出现问题的，进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系，确认gyro_在这个函数执行的时候，地址是否正确。

从上面来看在此处函数执行的时候，对应的gyro的地址还没有变成错误的0x1388。

从这里我们基本可以确认到，函数从 第20帧对应位置执行之后再到17帧的函数的时候，执行函数的地址发生了改变 然后开始进入校对代码的环节。

这个时候校对不是看代码执行的具体情况，因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。

最终找到了一个出现线程调用先后顺序导致变量没有准备好，出现的死机情况。

示例二：另一个指针问题

进入之后第一件事情 使用 bt命令查看堆栈信息

这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。

这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。

thread apply all bt

除了bt大家也可以打印自己需要的其他信息

thread apply all command //所有线程都执行命令

对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。

此时我们发现led一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个bug。

示例三：内存溢出

进入之后第一件事情 使用 bt命令查看堆栈信息

此时发现当前堆栈信息也无法进行定位到问题。

Dann haben wir thread apply all bt verwendet, aber beim ersten Mal haben wir die entsprechende hand_exit-Funktion nicht gesehen

Dann verwenden wir info locals, um die gespeicherten lokalen Variableninformationen anzuzeigen

info f addr打印通过addr指定帧的信息。info argsDrucken Sie den Wert der Funktionsvariablen.

info locals Lokale Variableninformationen drucken.

info catchDrucken Sie die Informationen zur Ausnahmebehandlung in der aktuellen Funktion aus.

Lokale Variablen weisen auch keine offensichtlichen Hinweise auf Zeigerfehler oder Daten außerhalb der Grenzen auf.

Also verwenden wir den Befehl p, um die in den Rahmeninformationen gespeicherten variablen Informationen auszudrucken.

Durch das Drucken dieser variablen Informationen, von denen wir glauben, dass sie eine hohe Fehlerquote aufweisen, können sie uns bei der Urteilsfindung helfen. Allerdings kann dieser Ausdruck den Ort des Problems nicht bestätigen.

Dann schauen wir uns noch einmal die Stack-Informationen aller Threads an. Schließlich sah ich einen abnormalen Parameter. Dieser Wert war sehr groß und etwas abnormal.

Dann überprüfen wir den entsprechenden Quellcode-Speicherort. Da es sich um eine C++-Bibliothek handelt, schauen wir uns den Code direkt am Kompilierungsspeicherort an.

Schauen Sie sich zuerst die in Bild 7 angezeigten Informationen anstl_algobase.h:465

Nachdem wir den entsprechenden Codespeicherort geöffnet hatten, stellten wir fest, dass der Parameter **__n** der Parameter für die Menge des zugewiesenen Speicherplatzes ist.

Vor und nach der Ausführung noch einmal ansehen stl_vector.h:343

Der jetzt übergebene __n ist ungefähr ein Einheitswert von mehr als 100 Millionen, und der tatsächliche Arbeitsspeicherort des Codes erfordert keine so große Speicherplatzzuweisung. Es wird also bestätigt, dass hier ein Problem vorliegt. Nach dem Vergleich des Speicherorts der Codeausführung und der globalen Verwendung der entsprechenden Variablen wird grundsätzlich festgestellt, dass die Warteschlange von Multithreads verwendet wird und die Sperre nicht ordnungsgemäß verwendet wird Mehrere Threads in den Ausgabe- und Eingabevorgängen werden unter extremen Umständen im selben Bereich ausgeführt, was diesmal zum Absturz des Codes führt.

Fazit

Dies ist die Analyse der Coredump-Dateien in dem von mir geteilten Projekt. Wenn Sie bessere Ideen und Bedürfnisse haben, können Sie mich gerne als Freund hinzufügen, um zu kommunizieren und zu teilen.

Zusätzlich zu den in meinem Artikel verwendeten Befehlen können Sie auch weitere Befehle verwenden, um das GBD-Debugging zu unterstützen und unsere Coredump-Datei zu überprüfen. Zeigen Sie beispielsweise den Assemblercode usw. an. Es gibt immer noch viele Artikel über GDB-Debugging-Befehle im Internet. Sie können auch andere Artikel lesen, die Ihnen bei der Verwendung der Befehle helfen.

Das obige ist der detaillierte Inhalt vonPraktische Weitergabe der Linux-Entwicklungs-Coredump-Dateianalyse. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!