Tracing corruption de mémoire sur un serveur linux de production
https://stackoverflow.com/questions/1182837
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Les gars, pourriez-vous s'il vous plaît recommander un outil pour repérer une corruption de mémoire sur un serveur multithread de production construit avec c ++ et travaillant sous x86_64 linux? Je suis actuellement face le problème suivant:. Toutes les quelques heures de plantage de mon serveur avec une erreur de segmentation et la décharge de base montre que l'erreur se produit dans malloc / calloc qui est certainement un signe de mémoire étant corrompu quelque part
En fait, je l'ai déjà essayé quelques outils sans beaucoup de chance. Voici mon expérience jusqu'à présent:
-
Valgrind est un grand (je dirais même mieux) outil mais il ralentit le serveur trop le rendant inutilisable dans la production. Je l'ai essayé sur un serveur scène et il m'a vraiment aidé à trouver des problèmes liés à la mémoire, mais même après les fixer, je reçois toujours des accidents sur le serveur de production. J'ai couru mon serveur de scène sous Valgrind pendant plusieurs heures, mais pas encore pu repérer des erreurs graves.
-
ElectricFence est dit être un vrai porc de mémoire, mais je ne pouvais même pas le faire fonctionner correctement. Il segfaults presque immédiatement sur le serveur scène dans des endroits étranges au hasard où Valgrind n'a pas montré de problèmes du tout. Peut-être que ElectricFence ne supporte pas bien enfiler? .. Je ne sais pas.
-
DOUMA - même histoire que ElectricFence mais pire encore. Alors que EF a produit des coredumps avec backtraces lisibles DOUMA me montre que « ????? » (et oui serveur est construit avec le drapeau -g sûr)
-
dmalloc - J'ai configuré le serveur pour l'utiliser au lieu de routines standard malloc mais il se bloque au bout de quelques minutes. Fixation d'un gdb au processus révèle qu'il est accroché quelque part dans dmalloc: (
Je deviens peu à peu fou et ne savent pas quoi faire. Je les outils suivants pour être jugé: mtrace, mpatrol mais peut-être quelqu'un a une meilleure idée
?J'apprécierais toute aide à ce sujet.
Mise à jour: J'ai réussi à trouver la source du bug. Cependant je l'ai trouvé sur le serveur de scène pas la production en utilisant un Helgrind / DRD / tsan - il y avait un datarace entre plusieurs threads qui ont abouti à la corruption de la mémoire. La clé était d'utiliser de valgrind propres répressions puisque ces outils ont montré trop de faux positifs. Cependant, je ne sais pas vraiment comment cela peut être découvert sur le serveur de production sans ralentissements importants ...
La solution 3
Folks, j'ai réussi à trouver la source du bug. Cependant je l'ai trouvé sur le serveur en utilisant étape Helgrind / DRD / tsan - il y avait un datarace entre plusieurs threads qui ont abouti à la corruption de la mémoire. La clé était d'utiliser bon valgrind depuis ces outils répressions ont montré trop de faux positifs. Cependant, je ne sais pas vraiment comment cela peut être découvert sur le serveur de production sans ralentissements importants ...
Autres conseils
Oui, les problèmes de corruption de mémoire C / C sont difficiles. J'ai aussi utilisé plusieurs fois valgrind, parfois, il a révélé le problème et parfois pas.
Lors de l'examen de sortie valgrind ne tendent pas à ignorer le résultat trop vite. Parfois, après un temps considérable passé, vous verrez que valgrind vous a donné l'idée à la première place, mais vous l'ignora.
Un autre conseil est de comparer les modifications du code de version stable précédemment connu. Ce n'est pas un problème si vous utilisez une sorte de système de versionnage source (par exemple svn). Examinez toutes les fonctions liées à la mémoire (par exemple memcpy, memset, sprintf, nouveau, supprimer / supprimer []).
Compiler votre programme avec gcc 4.1 et le -fstack-protecteur-tout interrupteur. Si la corruption de mémoire est provoquée par écrasement de la pile cela devrait être en mesure de le détecter. Vous devrez peut-être jouer avec quelques-uns des paramètres supplémentaires de SSP.
Les Google perftools --- qui est Open Source --- peut être utile, voir le tas checker documentation .
Essayez celui-ci: http://www.hexco.de/rmdebug/ J'utilisé intensivement, son a un faible impact sur la performance (il principalement impacts quantité de mémoire RAM), mais l'algorithme d'allocation est le même. Il est toujours assez éprouvée pour trouver des bugs d'allocation. Votre programme se bloque dès que le bogue se produit, et il aura un journal détaillé.
Je ne sais pas si elle aurait pris votre bug particulier, mais la variable d'environnement MALLOC_CHECK_ ( malloc page de manuel ) excitait contrôle supplémentaire dans l'implémentation par défaut Linux malloc et ne dispose généralement pas un coût d'exécution important.
