Au fil des ans, j'ai beaucoup écrit sur la façon de résoudre les problèmes liés aux logiciels dans le monde informatique en général, et sous Linux, en particulier. Après tout, c'est mon pain quotidien depuis longtemps, et je suis toujours passionné par l'art de la résolution de problèmes. L'un des sujets que j'ai abondamment couverts est gdb, le débogueur logiciel par excellence. Le seul problème est que vous devez innit pour gagner.
Ce que je veux dire par là - gdb est excellent si vous pouvez reproduire vos problèmes. Mais si vous exécutez un logiciel dans une configuration de production, vous n'aurez peut-être pas le luxe de continuer à déclencher des problèmes encore et encore. La capacité de capturer puis de rejouer les bogues est un atout majeur, et elle se présente sous la forme de RR, un outil conçu pour aider à déboguer les exécutions enregistrées de logiciels de manière précise et déterministe. Voyons ce que ça donne.
RPrêt, prêt, prêt
Essentiellement, RR est gdb et gdb est RR. L'idée est simple et la réalisation élégante. Vous exécutez votre outil avec rr, vous capturez l'exécution (et l'échec), puis vous rejouez l'enregistrement autant de fois que vous le souhaitez, loin de l'environnement de production. De plus, s'il existe des problèmes insaisissables, vous pourrez peut-être saisir un scénario reproductible, ce qui vous permettra de déterminer plus rapidement la cause première et de résoudre le problème.
J'ai installé et configuré RR dans Fedora 32. Assez simple. Maintenant, l'exécution nécessite une certaine attention aux détails. Si vous exécutez le programme en tant qu'utilisateur régulier, vous pouvez voir un avertissement indiquant que RR ne peut pas réellement saisir les événements privilégiés du noyau. Vous pouvez changer cela, et vous n'aurez alors plus besoin de sudo. Semblable à ce que nous avons vu avec perf vraiment. Doux.
rr record ./seg
rr a besoin de /proc/sys/kernel/perf_event_paranoid <=1, mais c'est 2.
Changez-le en 1, ou utilisez 'rr record -n' (lent).
Envisagez de mettre 'kernel.perf_event_paranoid =1' dans /etc/sysctl.conf
Il existe de nombreuses façons de changer cela. Attribuez une valeur à /proc, utilisez sysctl -w pour écrire la valeur, modifiez manuellement le fichier /etc/sysctl.conf, puis rechargez la configuration. Quelle que soit la méthode que vous choisissez, vous obtiendrez de meilleures performances et la possibilité de retracer tous les événements nécessaires.
sudo sysctl -w kernel.perf_event_paranoid=1
Exemple d'erreur de segmentation
Pour voir à quel point RR est pratique et utile, j'ai décidé d'utiliser le même exemple d'erreur de segmentation du didacticiel gdb. En gros, une boucle avec malloc() qui conduira à un défaut de segmentation :
#include
#include
main()
{
int *pointer;
int je ;
pointeur =malloc(sizeof(int));
for (i =0; 1; i++)
{
pointer[i]=i;
printf("pointeur[%d] =%d\n", je, pointeur[je]);
}
retour(0);
}
gcc -g seg.c -o seg
seg.c:4:1 :avertissement :le type de retour par défaut est 'int' [-Wimplicit-int]
4 | main()
| ^~~~
Enregistrement RR et relecture RR
Les deux principales fonctions utilisées par RR - enregistrer et rejouer.
rr record ./seg
...
pointer[33621] =33621
pointer[33622] =33622
pointer[33623] =33623
Défaut de segmentation (cœur abandonné)
Veuillez noter que l'exécution réelle sera plus lente que d'habitude. Cela signifie que si vous avez des problèmes liés au temps, RR peut ne pas être utile. Assez similaire à ce que nous avons vu avec strace vraiment. Vous voulez des problèmes déterministes qui peuvent être reproduits de manière fiable (dans les bonnes conditions, c'est-à-dire).
Quoi qu'il en soit, une fois que nous aurons enregistré le problème, nous pourrons le rejouer :
rr rejouer
La première fois que RR a été chargé, il m'a averti que les symboles de débogage n'étaient pas disponibles - c'est très important si vous voulez vraiment pouvoir résoudre le problème. Ce n'est en aucun cas spécifique à RR, mais c'est quelque chose à prendre en compte - vous pouvez installer les packages manquants si vous le souhaitez, le programme répertorie même la commande exacte que vous pouvez utiliser pour le faire.
Débogage à distance avec 127.0.0.1:7747
Lecture des symboles depuis /lib64/ld-linux-x86-64.so.2...
(Aucun symbole de débogage trouvé dans /lib64/ld-linux-x86 -64.so.2)
0x00007f25ce73e110 dans _start () de /lib64/ld-linux-x86-64.so.2
Infos de débogage séparées manquantes, utilisez :dnf debuginfo-install glibc-2.31-2 .fc32.x86_64--Tapez
Une fois l'interface RR chargée, vous êtes en terre gdb. Les commandes sont les mêmes. Vous pouvez définir des points d'arrêt, puis utiliser des conditions pour déterminer à quel moment ces points d'arrêt doivent être réellement activés et l'exécution de la tâche arrêtée.
pause 10
condition 1 i ==33610
continuer
Et la session de débogage ressemblera à :
(rr) suivant
pointer[33611] =33611
9 for (i =0; 1; i++)
(rr) next
11 pointer[i]=i;
(rr) suivant
Le programme a reçu le signal SIGSEGV, Défaut de segmentation.
0x000000000040116a dans main() at seg.c:11
11 pointer[i]=i;
Maintenant, vous pouvez aller plus loin et effectuer des vérifications supplémentaires. La principale différence est que tout cela se produit sur une instance enregistrée de votre logiciel, de sorte que vous n'interférez pas potentiellement avec l'utilisation réelle de vos services et applications. Idéalement, vous avez besoin d'une configuration intelligente capable de détecter automatiquement les problèmes et de les enregistrer, mais c'est une toute autre histoire.
Conclusion
Je n'ai pas passé trop de temps à utiliser RR, mais j'aime ce que je vois. Le programme utilise les fondamentaux familiers et robustes de gdb, ce qui signifie que vous n'avez pas besoin de réapprendre le dépannage Linux à partir de zéro. En plus de cela, il ajoute une couche de flexibilité puissante, vous permettant de minimiser la pression temporelle qui est souvent associée aux problèmes informatiques - comme le plantage de logiciels. Vous pouvez enregistrer et rejouer à votre convenance. Cela signifie également que vous êtes plus susceptible de trouver le problème, surtout si vous avez affaire à des exécutions de tâches longues et compliquées.
J'espère que vous trouverez ce court tutoriel utile. Dans un monde où il y a dix chefs pour chaque repas et cinquante outils Linux redondants pour chaque besoin, il est agréable de voir un logiciel qui offre des fonctionnalités supplémentaires significatives plutôt qu'une refonte du même vieux. Eh bien, vous avez maintenant un autre utilitaire dans votre arsenal, ce qui signifie également une excuse de moins pour ne pas pouvoir résoudre ces problèmes logiciels embêtants assez rapidement. C'est comme ça que ça marche, non.