11 commentaires
As-tu essayé d'utiliser AddressSanitizer (ASan) à la compilation ? C'est bien plus performant que valgrind et ça intercepte les accès invalides en temps réel.
Pas encore, mais mon binaire est assez lourd. Est-ce que l'overhead reste acceptable en production ou environnement de pré-prod ?
ASan ajoute environ 2x de consommation mémoire. Si tu ne peux pas te le permettre, essaye GWP-ASan, c'est conçu spécifiquement pour les bugs mémoire en production avec un impact minimal.
Je ne connaissais pas GWP-ASan. Je vais regarder la documentation. Merci pour le tips.
Vérifie aussi tes LD_PRELOAD, parfois une bibliothèque tierce corrompt le segment de données avant même que ton main ne démarre.
D'accord avec 3, vérifie avec ldd si une version différente de glibc n'est pas chargée par erreur.
Je vais auditer les dépendances. C'est une piste intéressante, on a récemment migré vers une nouvelle version de la glibc.
Si c'est la glibc, regarde du côté de MALLOC_CHECK_. En réglant la variable à 3, tu peux forcer un dump immédiat lors de la corruption.
Super, je tente export MALLOC_CHECK_=3 dès lundi sur l'environnement de test.
Pense aussi à générer un core dump pour analyser avec gdb le stack trace exact au moment du plantage.
Merci à tous pour ces retours. Je commence par MALLOC_CHECK_ et je passe sur AddressSanitizer si ça ne suffit pas.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous, je galère avec une corruption de heap intermittente dans un service C++ critique. Le binaire plante aléatoirement avec un
double free or corruptionsans message clair. J'ai déjà tenté d'utiliservalgrind, mais le surcoût mémoire fait disparaître le bug. Est-ce que quelqu'un aurait une approche plus légère pour isoler l'allocation fautive ?