Partage pratique d'analyse de fichiers coredump de développement Linux

Avant-propos :

Dans le développement Linux embarqué, l'analyse des fichiers coredump est une méthode courante, et nous pouvons souvent trouver des tutoriels d'utilisation associés sur Internet. Cependant, il existe peu d'articles sur la façon d'analyser les fichiers coredump des applications multithread. Aujourd'hui, je vais partager quelques cas que j'ai rencontrés en utilisation réelle, en espérant apporter un peu d'aide à tout le monde. En raison des limitations du code et de l'espace, je ne décrirai que les problèmes qui me semblent les plus distinctifs et j'utiliserai la réflexion sur le cadre pour résoudre de nombreuses situations de fichiers coredump rencontrées.

Auteur : La conscience existe toujours

Autorisation de réimpression et spectateurs : bienvenue pour suivre le compte public WeChat : Hamebayashi-kun

Ou ajoutez le WeChat personnel de l'auteur : become_me

---

Introduction à l'intrigue :

Lors du débogage d'une fonction, j'ai généré des fichiers coredump et différentes erreurs de programme se sont produites. Grâce à cette opportunité, j'aimerais le partager avec tout le monde. De manière générale, les fichiers coredump peuvent être générés en raison de pointeurs nuls, de tableaux hors limites, de versions multiples par plusieurs threads, d'un débordement de pile, etc. Ici, j'ai sélectionné quelques problèmes représentatifs en fonction des situations que j'ai rencontrées et je partage avec vous quelques solutions simples.

Tout d'abord, pour déboguer en conséquence, nous devons utiliser l'outil gdb. Avant de commencer à analyser le fichier coredump, vous devez vous familiariser avec les différentes commandes de gdb. Vous trouverez ci-dessous deux articles que j'ai déjà écrits sur le débogage de gdb :

Un article pour démarrer avec le débogage gdb sous Linux (1)

Un article pour démarrer avec le débogage gdb sous Linux (2)

Par conséquent, cet article n'entrera pas dans les détails de ces contenus, mais se concentrera uniquement sur les opérations réelles que nous devons effectuer lors de l'analyse des fichiers coredump.

Tout d'abord, nous devons déboguer à l'aide d'un fichier exécutable contenant des informations de débogage.

gdb executable_file coredump_file

Exemple 1 : échec de l'initialisation du pointeur

La première chose après avoir entré est d'utiliser la commande bt pour afficher les informations de la pile

Dans ce fichier coredump, nous pouvons facilement voir qu'il existe une différence de données claire entre l'adresse entrante d'une fonction et la fonction membre de la classe. Nous pouvons directement tirer une conclusion sur une partie aussi évidente, puis vérifier les détails.

f  n 

Sélectionnez les images par numéro d'image. Le numéro d'image peut être visualisé via la commande bt.

我们查看对应的第 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命令查看堆栈信息

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

Ensuite, nous avons utilisé thread apply all bt mais nous n'avons pas vu la fonction hand_exit correspondante la première fois

Ensuite, nous utilisons info locals pour afficher les informations sur les variables locales enregistrées

info f addr打印通过addr指定帧的信息。info argsImprimez la valeur de la variable de fonction.

info locals Imprimez les informations sur les variables locales.

info catchImprimez les informations de gestion des exceptions dans la fonction actuelle.

Les variables locales n'ont également aucune indication évidente d'erreurs de pointeur ou de données hors limites.

Nous utilisons donc la commande p pour imprimer les informations variables enregistrées dans les informations du cadre.

En imprimant ces informations variables qui, selon nous, ont un taux d'erreur élevé, cela peut nous aider à prendre des décisions. Cependant, cette impression ne peut pas confirmer l'emplacement du problème.

Ensuite, nous réexaminons les informations de pile de tous les threads. Finalement, j'ai vu un paramètre anormal. Cette valeur était très grande et quelque peu anormale.

Ensuite, nous vérifions l'emplacement du code source correspondant. Puisqu'il s'agit d'une bibliothèque C++, nous regardons directement le code à l'emplacement de compilation.

Regardez d'abord les informations affichées dans l'image 7stl_algobase.h:465

Après avoir ouvert l'emplacement du code correspondant, nous avons constaté que le paramètre **__n** est le paramètre de la quantité d'espace alloué.

Revoir avant et après l'exécution stl_vector.h:343

Le __n transmis maintenant a une valeur unitaire d'environ 100 millions, et l'emplacement de travail réel du code ne nécessite pas une allocation d'espace aussi importante. Il est donc confirmé qu'il y a un problème ici.Après avoir comparé l'emplacement d'exécution du code et l'utilisation globale des variables correspondantes, il est essentiellement déterminé que la file d'attente est utilisée par plusieurs threads et que le verrou n'est pas utilisé correctement, ce qui entraîne plusieurs threads dans les opérations de sortie et d'entrée dans des circonstances extrêmes, cela sera fait dans la même zone, provoquant le crash du code cette fois.

Conclusion

Il s'agit de l'analyse des fichiers coredump du projet que j'ai partagé. Si vous avez de meilleures idées et besoins, n'hésitez pas à m'ajouter comme ami pour communiquer et partager.

En plus des commandes utilisées dans mon article, vous pouvez également utiliser davantage de commandes pour aider au débogage de gbd afin de vérifier notre fichier coredump. Par exemple, affichez le code assembleur, etc. Il existe encore de nombreux articles sur les commandes de débogage de gdb sur Internet. Vous pouvez également lire d'autres articles pour vous aider à utiliser les commandes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!