Fuites de mémoire

**v4np13** · 06/05/2007, 20h05

Bonjour,
je viens de reprendre le développement du pacman. Et je m'étais déjà rendu compte que j'avais une/des fuite(s) de mémoire. On m'a conseillé d'utiliser valgrind sur Ubuntu, mais j'ai du mal à bien interpréter les résultats. Auriez-vous un explicatif assez complet quelque part,...?

Autrement, j'utilise beaucoup de structures, mais je me demande si je les utilise bien. Je passe en paramètre les adresses des structures, mais faut-il jouer avec malloc (ce que je ne fais pas pour le moment).

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct joueur pacman; 
//remplissage de la structure du genre pacman.nbVies = 3;
deplacerJoueur(&pacman); 
 
//dans deplacerJoueur(struct joueur *pacman)
pacman->nbVies--;

Faut-il que je fasse comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
struct joueur *pacman; 
pacman = malloc(sizeof(struct joueur));
//remplissage de la structure du genre pacman->nbVies = 3;
deplacerJoueur(pacman); 
 
//dans deplacerJoueur(struct joueur *pacman)
pacman->nbVies--;

L'avantage de la deuxième méthode, c'est que je peux faire free(pacman); Mais je pense utiliser toujours les mêmes éléments. Ca pourrait expliquer une fuite de mémoire, mais je ne suis pas sûr. Je préfère me référer à vous avant d'effectuer les changements.

Merci d'avance.

**khayyam90** · 07/05/2007, 00h04

Bien le bonsoir,

Pour ce qui est de Valgrind, tu as de la doc sur wikipedia, ça peut être un début.

Le choix structures dynamiques/statiques va dépendre de l'usage que tu fais de tes structures, si le nombre de ces variables est toujours le même, si tu souhaites en gérer finement la mémoire.

Personnellement, je conseillerais d'utiliser une version dynamique, ça permettrait de se rapprocher d'une programmation objet en créant des constructeurs et destructeurs, qui appellent eux-mêmes les malloc et les free.

Une petite chose, dans la version statique, l'accès aux champs d'une structure se fait avec un . et non ->
De plus, dans la méthode statique, si jamais la structure joueur contient des champs dynamiques, il faudra aussi penser à les libérer explicitement.

**berg** · 07/05/2007, 01h43

Si tu débute avec valgrind, cela peut peut-etre t aider :
http://www.info.fundp.ac.be/~hto/enc...troduction.pdf
Pour ce qui est version statique et dynamique, cela depend surtout de sa duree de vie.

**souviron34** · 07/05/2007, 13h18

je ne sais pas si ddd existe sur Ubuntu, mais c'est ce que j'utilise.

Quand à ta question de départ, aucune importance, ce n'est certainement pas de là que je viens l'erreur.

Par contre, sans en savoir plus sur le code, impossible d'en dire plus...

**Franck.H** · 07/05/2007, 13h23

Envoyé par souviron34

je ne sais pas si ddd existe sur Ubuntu, mais c'est ce que j'utilise.

Bin disons qu'il existe sur Linux tout simplement, il suffit au pire des cas de l'installer

**v4np13** · 07/05/2007, 13h31

Je peux vous montrer le code si vous voulez mais ça fait plus de 1000lignes... J'ai pas tellement envie de vous imposer ça.

Il y a deux sources de fuite possibles: les structures et l'utilisation de SDL. Mais la fuite est assez colossale en utilisation de mémoire, ça passe de quelques Ko à plusieurs dizaines de Mo. L'augmentation est continue, j'en déduis que ça vient forcément d'une boucle.

Je vais jeter un oeil à ddd.

Autrement valgrind ne me dit pas ou se trouve les fuites dans mon code mais il me signale des erreurs dans les fichiers sources de SDL. Je vous copierai une partie du rendu au soir (mon code est resté chez moi).

**v4np13** · 07/05/2007, 17h11

Voici comme je vous disais une partie du valgrind qui ne m'aide pas des masses:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
==6922== Invalid read of size 4
==6922==    at 0x4014770: (within /lib/ld-2.5.so)
==6922==    by 0x4005B69: (within /lib/ld-2.5.so)
==6922==    by 0x4007995: (within /lib/ld-2.5.so)
==6922==    by 0x4010D94: (within /lib/ld-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x40108ED: (within /lib/ld-2.5.so)
==6922==    by 0x43B7C2C: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x43B82AB: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x43B7B63: dlopen (in /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x408EB9C: SDL_LoadObject (in /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x40953AE: (within /usr/lib/libSDL-1.2.so.0.11.0)
==6922==  Address 0x47C6508 is 24 bytes inside a block of size 25 alloc'd
==6922==    at 0x4021620: malloc (vg_replace_malloc.c:149)
==6922==    by 0x4007F33: (within /lib/ld-2.5.so)
==6922==    by 0x4010D94: (within /lib/ld-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x40108ED: (within /lib/ld-2.5.so)
==6922==    by 0x43B7C2C: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x43B82AB: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x43B7B63: dlopen (in /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x408EB9C: SDL_LoadObject (in /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x40953AE: (within /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x409E8CB: (within /usr/lib/libSDL-1.2.so.0.11.0)
--6922-- Reading syms from /usr/lib/libXrender.so.1.3.0 (0x48D4000)
--6922-- Reading debug info from /usr/lib/libXrender.so.1.3.0...
--6922-- ... CRC mismatch (computed A206CFC4 wanted EEB9A1A6)
--6922--    object doesn't have a symbol table
--6922-- Reading syms from /usr/lib/libXrandr.so.2.1.0 (0x48DC000)
--6922-- Reading debug info from /usr/lib/libXrandr.so.2.1.0...
--6922-- ... CRC mismatch (computed 1D2EC385 wanted D95A4DEC)
--6922--    object doesn't have a symbol table
--6922-- REDIR: 0x4158DA0 (free) redirected to 0x40211B5 (free)
--6922-- REDIR: 0x415BDF0 (strncmp) redirected to 0x40224E0 (strncmp)
--6922-- REDIR: 0x415D030 (stpcpy) redirected to 0x4022B10 (stpcpy)
--6922-- REDIR: 0x4158F90 (realloc) redirected to 0x402164A (realloc)
==6922== 
==6922== Invalid read of size 4
==6922==    at 0x4014759: (within /lib/ld-2.5.so)
==6922==    by 0x400D2A9: (within /lib/ld-2.5.so)
==6922==    by 0x4009812: (within /lib/ld-2.5.so)
==6922==    by 0x41F33D2: (within /lib/tls/i686/cmov/libc-2.5.so)
==6922==    by 0x41F3639: _dl_sym (in /lib/tls/i686/cmov/libc-2.5.so)
==6922==    by 0x43B7DE7: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x43B82AB: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x43B7D72: dlsym (in /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x408EADA: SDL_LoadFunction (in /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x4094D6C: (within /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x4095E97: (within /usr/lib/libSDL-1.2.so.0.11.0)
==6922==  Address 0x47C60EC is 20 bytes inside a block of size 22 alloc'd
==6922==    at 0x4021620: malloc (vg_replace_malloc.c:149)
==6922==    by 0x4007F33: (within /lib/ld-2.5.so)
==6922==    by 0x4010D94: (within /lib/ld-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x40108ED: (within /lib/ld-2.5.so)
==6922==    by 0x43B7C2C: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x400CFA5: (within /lib/ld-2.5.so)
==6922==    by 0x43B82AB: (within /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x43B7B63: dlopen (in /lib/tls/i686/cmov/libdl-2.5.so)
==6922==    by 0x408EB9C: SDL_LoadObject (in /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x40953AE: (within /usr/lib/libSDL-1.2.so.0.11.0)
==6922==    by 0x409E8CB: (within /usr/lib/libSDL-1.2.so.0.11.0)

Il parle de tout sauf de mes fichiers sources.

Passons à ddd, voici ce qu'il me retourne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216284992 (LWP 7163)]
0xb7f819ec in TTF_SizeUNICODE () from /usr/lib/libSDL_ttf-2.0.so.0

Il s'arrête là et ne vas pas plus loin... Il a à peine ouvert ma fenêtre mais pas chargé mon interface graphique,... Juste pour préciser, je ne fais pas d'appel à TTF_SizeUNICODE mais à TTF_Init (), TTF_OpenFont (), TTF_RenderText_Blended() et TTF_CloseFont()

**v4np13** · 07/05/2007, 17h45

Je viens d'éliminer une grosse partie des "problèmes", il faut initialiser TTF avant de déclarer des variables de type TTF_Font...

Ca ne règle pas le problème de la fuite bien sur mais ça m'élimine pas mal de retour d'erreur.

**v4np13** · 07/05/2007, 19h38

Sorry si je me réponds, mais ça pourrait en aider d'autres

J'ai trouvé ma fuite de mémoire, j'utilisais : TTF_RenderText_Blended (police, scoreStr, couleurBlanche); sans faire de SDL_FreeSurface(); Ca peut paraître bête pour certains, mais je ne savais pas qu'il en fallais

Par contre valgrind me signale encore un truc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
==9420==  Address 0x47DD056 is 14 bytes inside a block of size 16,384 alloc'd
==9420==    at 0x402095F: calloc (vg_replace_malloc.c:279)
==9420==    by 0x45EE346: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9420==    by 0x4093BED: (within /usr/lib/libSDL-1.2.so.0.11.0)
==9420==    by 0x409E987: (within /usr/lib/libSDL-1.2.so.0.11.0)
==9420==    by 0x408B8B0: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.0)
==9420==    by 0x405E1D0: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.0)
==9420==    by 0x405E216: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.0)
==9420==    by 0x8048FF4: main (main.c:87)

Après quelques recherches, je ne trouve pas l'erreur. Voici le début de la fonction main:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int main (){
  if ((SDL_Init(SDL_INIT_VIDEO)) == -1){  //ligne 87
    fprintf(stderr,"Erreur a l'initialisation de l'ecran  : %s\n",SDL_GetError ());
    exit(EXIT_FAILURE);
  }
 
  if ((TTF_Init()) == -1){
    printf("TTF_Init: %s\n", TTF_GetError());
    exit(EXIT_FAILURE);
  }
 
  //Appeler la fonction SDL_Quit en cas de fermeture du programme par exit() ou return;
  atexit(SDL_Quit);
 
  SDL_Surface *ecran = NULL, *imgPacman = NULL,*imgIcone = NULL, *txtPacman = NULL;
  TTF_Font *policeGd = NULL;
  SDL_Rect position;
  SDL_Event event;
  .....

Je termine bien entendu ma fonction main par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
  TTF_CloseFont(policeGd);
  TTF_Quit();
  SDL_FreeSurface(imgPacman);
  SDL_FreeSurface(imgIcone); 
  SDL_FreeSurface(txtPacman);
  SDL_Quit();

Où est le problème?

Merci d'avance

**v4np13** · 08/05/2007, 09h36

Personne n'a d'idée pour l'erreur avec SDL_Init ? Vous n'avez jamais rencontré cela avec valgrind ?

**Emmanuel Delahaye** · 08/05/2007, 10h17

Envoyé par v4np13

Personne n'a d'idée pour l'erreur avec SDL_Init ? Vous n'avez jamais rencontré cela avec valgrind ?

A l'évidence, c'est un problème SDL. Il faut leur faire un rapport de bug...

**v4np13** · 08/05/2007, 14h51

Je viens d'approfondir le problème, en simplifiant au maximum le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <SDL/SDL.h>
 
int main (){
  atexit(SDL_Quit);
 
  if ((SDL_Init(SDL_INIT_VIDEO)) == -1){ //line 7
    fprintf(stderr,"Error at SDL_Init  : %s\n",SDL_GetError ());
    exit(EXIT_FAILURE);
  }
 
  SDL_Quit();
  return 0;
}

Voici le résultat de valgrind:

==22717== Address 0x47D6456 is 14 bytes inside a block of size 16,384 alloc'd
==22717== at 0x402095F: calloc (vg_replace_malloc.c:279)
==22717== by 0x45EE346: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==22717== by 0x4093BED: (within /usr/lib/libSDL-1.2.so.0.11.0)
==22717== by 0x409E987: (within /usr/lib/libSDL-1.2.so.0.11.0)
==22717== by 0x408B8B0: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.0)
==22717== by 0x405E1D0: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.0)
==22717== by 0x405E216: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.0)
==22717== by 0x804860C: main (testmemoire.c:7)
....
....
==22717== LEAK SUMMARY:
==22717== definitely lost: 10 bytes in 2 blocks.
==22717== possibly lost: 0 bytes in 0 blocks.
==22717== still reachable: 23,249 bytes in 393 blocks.
==22717== suppressed: 0 bytes in 0 blocks.

Il n'y a que 10 octets de perdu, est-ce important au point de leur signaler ? C'est une petite fuite de mémoire, mais que sont les 23,249 bytes dans 393 blocks ?

**souviron34** · 08/05/2007, 15h14

il est TOUJOURS important de faire un bug report sur un problème tel que celui-ci, quelle que soit la taille de la fuite..

C'est une erreur dans un PRODUIT, pas dans un bidouillage entre copains....

**v4np13** · 08/05/2007, 15h36

Ok, le bug est rapporté, affaire à suivre: bugzilla.libsdl.org

Fuites de mémoire

C

Discussions similaires

Partager

Partager