[C] Méthodes détection buffer overflow/overrun

Version imprimable

24/05/2013, 16h18
Aspic

[C] Méthodes détection buffer overflow/overrun
Bonjour à tous,

Je cherche à savoir s'il existe des méthodes pour détecter les buffers overflows/overrun en C ?

Je m'explique : voilà un code simple:
Code:

1 2 3 4 5 int main() { int*a = (int*)malloc(10*sizeof(int)); a[10] = 50; // overflow }
Je surcharge déjà les malloc/free avec des macros pour tracker les fuites de mémoire.

La seule solution que j'ai trouvée pas très robuste est de "surallouer" la zone mémoire et de la préremplir avec une séquence connue. Et si cette zone est corrompue alors il y a overflow. Exemple : je demande une allocation de 10 entiers mais j'en alloue en fait 20 et je mets dans les cases 10 à 20, une séquence connue donc si je fais un overflow, je risque de détruire cette zone. Mais c'est pas superbe car si je fais un tab[100] = 50; ma solution ne marche pas... :(

Je sais qu'il existe de outils (le plus souvent payant pour cela) mais je voudrais avoir ma solution customisée ;)

Est-il possible de détecter ce type d'erreur ?

Même question mais pour un tableau statique ?

Merci beaucoup :)
24/05/2013, 16h27
Metalman

Alors à l'exécution même "hors mode debug", je ne sais pas....

Mais valgrind (avec les flags de debug à la compilation) pourra te dire quand tu dépasses très légèrement des tableaux, et quand tu dépasses amplement.
Évidement, ça fonctionne lors de la phase de debug, donc pas possible avec ça de rattraper des cas non-prévus (mais il y aurait un problème de conception à ce moment là ?)
24/05/2013, 16h57
Aspic

Citation:

Envoyé par Metalman

Alors à l'exécution même "hors mode debug", je ne sais pas....

Mais valgrind (avec les flags de debug à la compilation) pourra te dire quand tu dépasses très légèrement des tableaux, et quand tu dépasses amplement.
Évidement, ça fonctionne lors de la phase de debug, donc pas possible avec ça de rattraper des cas non-prévus (mais il y aurait un problème de conception à ce moment là ?)

Oui Valgrind détecte les dépassements de tableaux.
En fait la question était plutôt comment fait-il cela ?
A mon avis, ca doit pas être du tout facile mais au cas où une solution m'échappe, je pose quand même la quesiton :mouarf:
24/05/2013, 17h05
Metalman

Normalement il override les mallocs en effet...
Après, hormis ce que tu supposes, il faudrait lire la doc de Valgrind qui explique beaucoup ces choses (et qui est gratuit + open source il me semble) !
24/05/2013, 17h12
kwariz

Bonjour,

Valgrind ne détecte que les dépassement des «tableaux» mallocés (cf la faq).
Il y a bien une option -fbounds-check mais elle n'est pas reconnue par le front-end C de gcc.
Si tu compiles au moins en O2 tu as l'option -Warray-bounds qui sera activée en même temps que -Wall ...
Mais bon on reste en C et ce que tu demandes ferait se lever les aficionados de la perf qui te traiteraient d'hérétique ...
24/05/2013, 21h31
Aspic

Citation:

Envoyé par kwariz

Il y a bien une option -fbounds-check mais elle n'est pas reconnue par le front-end C de gcc.

C'est quoi le front-end C ? :aie:
24/05/2013, 22h09
kwariz

Pour faire simple, gcc signifie Gnu Compiler Collection. gcc peut compiler plusieurs langages (c, c++, ada, fortran, java, ...), il y a un front-end pour chaque langage qui se charge de parser le source et de le transformer en une forme intermédiaire qui sera compilée par un back-end pour une plateforme particulière.
24/05/2013, 23h26
vdary

Bonjour,

Address Sanitizer (ASAN) est un plugin à Clang, qui est lui même un frontend C, C++, objectif C, C++ pour le compilateur LLVM.

Les erreurs de manipulation mémoire qu'il peut détecter sont les suivante:

-use after free
-stack et heap overflow
-global out of bounds
-double free

Ce plugin insére des gardes fou à la compilation qui stope l'exécution du programme lors d'une corruption mémoire même si elle n'empeche pas le déroulement du programme. De plus une trace très précise est fournit sur l'origine de la corruption mémoire.

Ce que je vien de dire est un extrait du magazine misc. Cependant pour répondre à ta question, ce plugin doit probablement posséder une très bonne documentation de ses mécanismes interne. D'autre part même si le projet est jeune, il à déjà fait ses preuves.

Sinon si tu veux plonger au plus profont du problème, il existe des formalisations mathématiques qui peuvent aidé à détecter du codes qui vas se tirer une balle dans le pied.

Je ne suis pas expert dans ce domaine mais il me semble que le langage ADA posséde un compilateur très pointilleux sur ces détails. typequement le compilateur ADA est suceptibe de te dire avant même que tu n'exécute ton binaire compilé que celui-ci vas ce tiré une balle dans le pied.

Bref ce genre de problème ne date pas d'aujourd'hui, il est toujours d'actualité et la documentation ne manque pas, je pense que tu trouvera ton bonheur.

En espérant t'avoir aidé.
25/05/2013, 09h16
Metalman

Oui mais l'ADA c'est autre chose : tu imposes des contraintes, donc le compilo va t'interdire certaines choses... du coup ton code devient "forcément" safe ! (ça devient un choix de paradigme + ou - safe, en gros)
Mais pas sûr que cela aide en C... :P

Mais l'idée de Clang avec ses vérifs est pas mal je trouve ! :)
25/05/2013, 10h31
Aspic

Citation:

Envoyé par kwariz

Pour faire simple, gcc signifie Gnu Compiler Collection. gcc peut compiler plusieurs langages (c, c++, ada, fortran, java, ...), il y a un front-end pour chaque langage qui se charge de parser le source et de le transformer en une forme intermédiaire qui sera compilée par un back-end pour une plateforme particulière.

Merci pour l'explication ;)

Clang j'en ai déjà entendu parlé, si je comprends bien c'est un autre compilateur qui remplace GCC ? Je vous avouerais que j'ai du mal à comprendre la phrase :

Citation:

The goal of the Clang project is to create a new C, C++, Objective C and Objective C++ front-end for the LLVM compiler.

Source : site officiel

Pour mes projets, j'utilise exclusivement GCC pour compiler et linker mes projets ;) et pas LLVM mais apparemment c'est compatible GCC.
25/05/2013, 13h42
kwariz

gcc n'est que l'outil le plus répandu pour compiler du C. Il y en a plusieurs qui sont sous licence libre comme clang ou open64, sous une licence plus ou moins permissive comme ceux d'intel(icc) ou oracle(ex sun, c99/solstudio pour l'ide) et d'autres payants (ibm). Tous sont utilisables sous linux. clang ne «remplace» pas gcc (du moins pour l'instant) dans le sens où le développement de gcc est abandonné au profit de clang. clang est toutefois préféré par apple et freebsd (qui l'adopte comme compilateur de base dans les prochaines versions je crois).

gcc et clang diffèrent sur certains points, gcc peut sembler plus monolithique par rapport à clang/llvm desquels tu peux indépendamment utiliser certaines fonctionnalités comme par exemple analyser à la volée (sans le compiler réellement) un code source pour immédiatement indiquer les erreurs dans un éditeur de texte. Mais les deux ont une approche similaire : un front-end par langage qui donne une forme de code intermédiaire qui est traité par un back-end qui l'utilise ensuite pour créer du code pour une plateforme. LLVM est en gros le nom d'une de ces représentation intermédiaire.

La détection statique des over/underflows est difficile, même si une vérification basique est faite. Je pensais que tu voulais t'orienter vers ce genre de vérification par gcc.

En ce qui concerne la détection runtime c'est plus délicat. Valgrind est un outil très répandu qui remplit bien son rôle et c'est vrai que les dèv gcc/c ne s'en sont pas trop préoccupé jusqu'à ce que les dèv clang/LLVM le fassent (enfin c'est mon point de vue). Ces derniers ont créé un module qui instrumente le code pour prévenir et diagnostiquer ce genre d'erreurs. Ça a été récupéré par les dèv gcc et intégré dans la dernière grosse version stable de gcc, la 4.8. Donc depuis la 4.8, tu as à ta disposition l'option -fsanitize=address (même option pour clang) qui lors d'un plantage te diagnostiquerait mieux l'erreur (j'emploie le conditionnel mais au bout du compte toute information supplémentaire est au final mieux qu'un segfault :)). Il y a un module d'aide au diagnostique pour les threads aussi qui a été intégré de LLVM vers gcc.
Il y a cependant un prix à payer. Tout comme pour l'utilisation avec valgrind le code est plus lent à l'exécution.

Comme je ne me suis pas encore amusé avec je ne pourrais pas t'en dire beaucoup plus. C'est une option qui me semble intéressante dans certains cas, pas forcément à utiliser aveuglément mais qui n'est certainement pas à négliger.
26/05/2013, 13h08
Franck.H

Une solution, que j'ai opté pour ma bibliothèque de chaîne de caractères, est de détecter la limite du tableau par rapport à l'argument fournit et de realloc le tout puis insérer la valeur supplémentaire.

Alors soit, tu créés un tableau avec 1 indice de plus que tu te gardes de côté pour déterminer la limite du tableau avec une valeur spéciale que tu définit en avance, soit tu créés un nouveau type par le biais d'une structure et tu créés à côté les fonctions qui la gères par rapport au type de données qu'elle peut y stocker.

J'ai toujours opté pour la seconde solution qui reste plus souple mais qui demande un peu plus de travaille car dans la solution 1 rien ne t'empêche de mettre une valeur dans ton dernier indice et tu te retrouve avec le même problème.
27/05/2013, 10h38
Aspic

Citation:

Envoyé par kwariz

gcc n'est que l'outil le plus répandu pour compiler du C. Il y en a plusieurs qui sont sous licence libre comme clang ou open64, sous une licence plus ou moins permissive comme ceux d'intel(icc) ou oracle(ex sun, c99/solstudio pour l'ide) et d'autres payants (ibm). Tous sont utilisables sous linux. clang ne «remplace» pas gcc (du moins pour l'instant) dans le sens où le développement de gcc est abandonné au profit de clang. clang est toutefois préféré par apple et freebsd (qui l'adopte comme compilateur de base dans les prochaines versions je crois).
[....]

Comme je ne me suis pas encore amusé avec je ne pourrais pas t'en dire beaucoup plus. C'est une option qui me semble intéressante dans certains cas, pas forcément à utiliser aveuglément mais qui n'est certainement pas à négliger.

Superbe explication ! Merci ;)
J'ai pas encore la dernière version de GCC, j'utilise la 4.7.2 actuellement. Mais je vais regarder de plus près cette nouvelle option après avoir mis mon compilo à jour ^^
Effectivement, je me doute que le code sera plus lent, je me souviens de mon jeu que j'avais passé sous Valgrind, j'avais perdu pas mal de FPS...

EDIT : Snif, la dernière version de gcc n'est pas dispo avec MinGW pour Windows :( Je devrais attendre...

Citation:

Envoyé par Franck.H

Alors soit, tu créés un tableau avec 1 indice de plus que tu te gardes de côté pour déterminer la limite du tableau avec une valeur spéciale que tu définit en avance, soit tu créés un nouveau type par le biais d'une structure et tu créés à côté les fonctions qui la gères par rapport au type de données qu'elle peut y stocker.

La première méthode est celle que j'utilise actuellement mais elle n'est pas fiable du tout :(
Sinon, je n'ai pas compris ta deuxième méthode, tu pourrais montrer un exemple ? Merci :)

Citation:

Envoyé par Aspic

La première méthode est celle que j'utilise actuellement mais elle n'est pas fiable du tout :(
Sinon, je n'ai pas compris ta deuxième méthode, tu pourrais montrer un exemple ? Merci :)

Quelque chose dans ce genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 typedef struct { int * val; size_t size; }MyInt; /* Ajout d'un entier. */ void my_int_add (MyInt ** ptr, int val) { /* Code... */ } /* Et pourquoi pas une fonction de suppression d'un entier. */ void my_int_remove (MyInt ** ptr, size_t index) { /* Code... */ } /* Suppression de l'objet complet. */ void my_int_free (MyInt ** ptr) { /* Code... */ }
Un peu comme si tu faisait une liste en fin d'compte. Je te le concèdes, c'est un peu différent à l'utilisation comparé à un tableau mais au moins ca te permet de construire des fonctions robustes.

Ici dans la structure tu as un membre en plus qui te permet de savoir combien d'entier tu as déjà ajouté à ton tableau d'entiers vu qu'à chaque appel de my_int_add() tu incrémentes le membre size ce qui te permet également de réallouer plus facilement l'espace pour ajouter un nouvel entier au tableau.

De plus, tout en continuant à passer par cet objet, tu pourrais construire, par exemple, une fonction de tri vu qu'en plus tu sais combien tu stock d'entiers donc facile ;)

J'ai souvent utilisé ce genre de concept et de toute façon en C tu n'as pas toujours le choix mais au moins c'est propre et j'ai jamais regretté ce genre d'approche.

Un petit exemple d'utilisation :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #define <stdlib.h> int main (void) { MyInt * p_int = NULL; /* Exemple d'appel à my_int_add. */ my_int_add (&p_int, 10); /* Exemple d'appel à my_int_free. */ my_int_free (&p_int); return EXIT_SUCCESS; }
Ici par exemple, la fonction my_int_add() allouerais d'elle même le pointeur p_int s'il vaut NULL (pour le premier ajout) au lieu de le faire autre part ce qui te permet de complètement spécialiser ta fonction et que ca reste transparent pour l'utilisateur si jamais quelqu'un devait l'utiliser à ta place ;)

Après c'est sûr, on sort du concept de la détection de fuites mémoire mais on entre dans la prévention voir même si c'est bien codé, dans l'élimination de fuites ;)

Tu peux même pousser le vice plus loin, le type MyInt, tu peux en faire carrément un type opaque comme ca, les membres de ta structure ne seront accessibles qu'à tes fonctions de gestion de ton objet et donc plus aucun moyen de déréférencer et d'accéder par accident à l'entier qui y est stocké et de le changer par maladresse :mrgreen:

27/05/2013, 17h49
cmoibal

La nouvelle version GCC-4.8 ajoute une nouvelle fonctionnalité qui peut vous être utile :
-fsanitize=address

Elle vous permet de "detect heap-, stack-, and global-buffer overflow as well as use-after-free bugs"

pour plus d'information : http://gcc.gnu.org/gcc-4.8/changes.html
27/05/2013, 17h52
Franck.H

Citation:

Envoyé par cmoibal

La nouvelle version GCC-4.8 ajoute une nouvelle fonctionnalité qui peut vous être utile :
-fsanitize=address

Elle vous permet de "detect heap-, stack-, and global-buffer overflow as well as use-after-free bugs"

pour plus d'information : http://gcc.gnu.org/gcc-4.8/changes.html

MingW ne l'intègre pas encore cette version, pour le moment ils en sont à la version 4.7 donc il doit faire sans :aie:
27/05/2013, 17h58
kwariz

Ah ? Pourtant sur le portail d'opensuse mingw est déjà proposé en version 4.8 pour de la cross-compilation. Il me semble aussi qu'il y a une release sur sourceforge ... mais là je ne connais pas trop ...
27/05/2013, 18h04
Franck.H

Citation:

Envoyé par kwariz

Ah ? Pourtant sur le portail d'opensuse mingw est déjà proposé en version 4.8 pour de la cross-compilation. Il me semble aussi qu'il y a une release sur sourceforge ... mais là je ne connais pas trop ...

Pourquoi pas, moi j'ai juste regardé la version fournie avec C::B donc à installer à part quoi :aie:
28/05/2013, 10h05
Aspic

Citation:

Envoyé par Franck.H

Après c'est sûr, on sort du concept de la détection de fuites mémoire mais on entre dans la prévention voir même si c'est bien codé, dans l'élimination de fuites ;)

Effectivement, mais je garde cette idée sous le coude ;)
Disons que dans mon cas c'est un peu plus complexe car disons que j'ai pas accès au code source mais j'ai le droit de surcharger les fonctions d'allocation de mémoire. Donc en n'ayant que comme point d'entrée malloc, realloc, calloc et free, difficile d'utiliser ta technique :(

Sinon je crois qu'il n'y a pas encore de release de la version 4.8 pour MinGW mais une version instable est disponible. Ce n'est pas grave, j'attendrais la release officiel sur sourceforge ;)

Merci à vous !
28/05/2013, 20h23
Franck.H

Citation:

Envoyé par Aspic

Disons que dans mon cas c'est un peu plus complexe car disons que j'ai pas accès au code source mais j'ai le droit de surcharger les fonctions d'allocation de mémoire. Donc en n'ayant que comme point d'entrée malloc, realloc, calloc et free, difficile d'utiliser ta technique :(

Bin il te faut rien de plus que free, malloc et ralloc pour monter tout ca et quelques conditions logique bien entendu mais si tu n'as pas le droit de procéder de la sorte soit :mouarf:

Je suis la conversation d'un peu loin et je me dis que j'allais tester ce que donne ton code dans Dr Memory. J'ai rajouté un free() pour ne laisser que l'erreur d'accès hors des bornes de la zone malloqué :

Code:

1
2
3
4
5
6
int main(void)
{
    int*a = (int*)malloc(10*sizeof(int));
    a[10] = 50; // overflow
    free(a);
}

J'obtiens comme rapport d'erreurs :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Dr. Memory version 1.5.1 build 6 built on Feb 25 2013 00:45:31
Application cmdline: ""D:\Users\pgradot\Documents\C\main.exe""
Recorded 75 suppression(s) from default C:\Program Files (x86)\Dr. Memory\bin\suppress-default.txt
 
Error #1: UNADDRESSABLE ACCESS: writing 0x003b0f80-0x003b0f84 4 byte(s)
# 0 main    
Note: @0:00:00.251 in thread 4644
Note: next higher malloc: 0x003b1938-0x003b1b58
Note: refers to 1 byte(s) beyond last valid byte in prior malloc
Note: prev lower malloc:  0x003b0f58-0x003b0f80
Note: instruction: mov    $0x00000032 -> (%eax)
 
DUPLICATE ERROR COUNTS:
 
SUPPRESSIONS USED:
 
ERRORS FOUND:
      1 unique,     1 total unaddressable access(es)
      0 unique,     0 total uninitialized access(es)
      0 unique,     0 total invalid heap argument(s)
      0 unique,     0 total GDI usage error(s)
      0 unique,     0 total warning(s)
      0 unique,     0 total,      0 byte(s) of leak(s)
      0 unique,     0 total,      0 byte(s) of possible leak(s)
ERRORS IGNORED:
     60 still-reachable allocation(s)
         (re-run with "-show_reachable" for details)
Details: d:\Users\pgradot\AppData\Roaming\Dr. Memory\DrMemory-main.exe.3224.000\results.txt

En revanche, il n'est pas plus capable que valgrind de détecter l'erreur si on accède hors des bornes d'un vrai tableau...

29/05/2013, 10h21
Aspic

Citation:

Envoyé par Franck.H

Bin il te faut rien de plus que free, malloc et ralloc pour monter tout ca et quelques conditions logique bien entendu mais si tu n'as pas le droit de procéder de la sorte soit :mouarf:

Le problème c'est que dans ton exemple, tu as définie des fonctions d'ajouts et de suppressions d'un entier évitant ainsi l'utilisation de l'opérateur []. Donc tu peux tout contrôler dont les overflows/underflows si on utilise tes fonctions ;)

Dans mon cas, n'ayant pas accès au code source (en fait c'est faux, j'y ai accès mais je ne dois pas le modifier), je n'ai accès qu'aux surcharges des fonctions d'alloc mais je ne peux pas overloader l'opérateur [] en C ... :(

Et puis le prototype de malloc est :

Code:

void* malloc(size_t size)

Si par exemple, j'ai 40 dans size, aucun moyen de savoir si il veut 10 entiers, 40 caractères ou une structure complexe de 40 octets.

Ou alors j'ai pas compris ton idée :mouarf:

@Bktero: Oui je sais que Dr Memory sait détecter ce genre d'erreur, d'ailleurs je me demande bien comment il fait ^^ D'ailleurs ca veut dire quoi" 60 still-reachable allocation(s)" ?
29/05/2013, 10h56
Bktero
Je viens de tester à l'instant un outil découvert il y a peu, cppcheck.

Comme répertoire de travail, je lui ai donné mon dossier avec mes bouts de code tests C, notamment ceux pour Developpez. Il m'a détecté une erreur sur le code (alors que je ne cherchais pas du tout à le tester sur ce problème là, c'est une découverte due au hasard ^^) :
Code:

1 2 3 4 5 void with_array(void) { int a[10] = {0}; a[10] = 50; // overflow }
Il y arrive aussi sur ça :
Code:

1 2 3 4 5 6 7 8 void more_subttle(void) { int a[10] = {0}; for(int i=0; i < 11; i++) { a[i]= i; } }
Je crois que je vais bien aimer cet outil !
29/05/2013, 10h59
ternel

En effet, c'est bon à prendre.
29/05/2013, 11h24
Metalman

Le "60 still reachables" signifie que tu as fait 60 mallocs et que tu ne les a pas free !
Pour les connaitre, tu devrais compiler avec les habituels flags de debug : -g -g3 -ggdb, puis lancer DrMemory sur le binaire résultat !
Ca t'affichera le fichier et la ligne exacte où il y a un malloc non free.
Par contre, pour corriger cela... il faut bien regarder dans toute la chaine fonctions laquelle demande à allouer et ne libère pas !

(Ce qui serait intéressant à vérifier maintenant, c'est si les allocations mémoires windoziennes sont "aussi" vérifiées (en pur C/Windows) par DrMemory)

Non, l'"erreur" n'est pas liée à cela...... car le free() est bien présent ! Et aussi parce que 4 bytes par int * 10 int = 40 bytes donc 60 ne collent pas ^^

De plus, si je commente le free() et repasse le binaire dans drmemory, j'obtiens vraiment une erreur :
Code:

1 2 Error #2: LEAK 40 direct bytes 0x00660f58-0x00660f80 + 0 indirect bytes # 0 main
Les still reachables semblent être des erreurs non graves, voir par exemple cette discussion de Stackoverflow.
EDIT : ou le point 1 de la doc de drmemory.

En ré-exécutant avec l'option indiquée, cela semble venir de dll. Extrait :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 REACHABLE LEAK 206 direct bytes 0x004a5f48-0x004a6016 + 0 indirect bytes REACHABLE LEAK 2748 direct bytes 0x004a6230-0x004a6cec + 0 indirect bytes REACHABLE LEAK 1152 direct bytes 0x006b09f0-0x006b0e70 + 0 indirect bytes REACHABLE LEAK 544 direct bytes 0x006b1938-0x006b1b58 + 0 indirect bytes REACHABLE LEAK 2897 direct bytes 0x006b1b60-0x006b26b1 + 0 indirect bytes REACHABLE LEAK 8 direct bytes 0x006b2f90-0x006b2f98 + 0 indirect bytes # 0 msvcrt.dll!_calloc_crt # 1 msvcrt.dll!_cwild # 2 msvcrt.dll!__getmainargs # 3 __mingw_CRTStartup # 4 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x777e9ef2 <ntdll.dll+0x39ef2>) # 5 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x777e9ec5 <ntdll.dll+0x39ec5>)

29/05/2013, 14h26
Metalman

Avec une DLL....
Je me souviens qu'à une époque on soupçonnait printf de faire 1 leak, mais en y repensant, cela doit faire partie des "still reachable" en effet.
Ca doit être une soixantaine de pointeurs encore référencés quelque part dans des globales.

EDIT : Bon bah le post suivant a l'air d'appuyer cette idée
29/05/2013, 14h26
ternel

Il me semble avoir lu que sous linux, il reste des unreachables avec certaines parties de la glibc.
Ce serait lié à des globales non déchargées (parce que la glibc reste utilisée partout)
Il était dit que ces unreachables n'augmentent pas, et ne devrait(?) pas poser de problèmes.

Cela dit, vérifie quand même ton code, mieux vaut être sûr.
29/05/2013, 14h38
kwariz

Oui, les outils comme valgrind ne peuvent (ne pourront jamais ?) pas ne pas donner de faux positifs. Certains sont référencés et cachés et dans la grande majorité des cas sont totalement inoffensifs (du moins ce sont les tous derniers à considérer lorsqu'on a un problème mémoire ...).
Certaines bibliothèques comme le GLib offrent la possibilité de modifier leur comportement via des variables d'environnement pour être une peu plus valgrind friendly. Je ne sais pas ce qu'il en est sur la plateforme win32/win64 ...
29/05/2013, 16h52
Aspic

D'accord, pour l'explication du still-reachable. en gros c'est pas (très) grave.

CppCheck, ca à l'air pas mal comme outil, j'espère qu'il est compatible MinGW sous windows :aie:

Je regarderais ca ce soir quand j'aurais un peu de temps. :D
29/05/2013, 17h38
Bktero

Citation:

CppCheck, ca à l'air pas mal comme outil, j'espère qu'il est compatible MinGW sous windows

Je suis sous Windows et utilise Codeblocks avec MinGW ;)
29/05/2013, 17h44
Aspic

Citation:

Envoyé par Bktero

Je suis sous Windows et utilise Codeblocks avec MinGW ;)

Il parait qu'avec CodeBlock, le plugin cppcheck est natif, pourtant je le trouve pas (faut dire que je suis encore à la version 8.02, c'est peut être pour ca :aie:)
29/05/2013, 18h23
Bktero

J'ai aussi lu ça sur le site de cppcheck après mon précédent message. J'ai une version récente de Codeblocks et il y est ;)
30/05/2013, 10h03
Aspic

Citation:

Envoyé par Bktero

J'ai aussi lu ça sur le site de cppcheck après mon précédent message. J'ai une version récente de Codeblocks et il y est ;)

C'est pas très grave, j'installerais le plugin manuellement ;)