Pourquoi Valgrind dit-il que le programme SDL de base fuit la mémoire?

Voici le programme SDL:Pourquoi Valgrind dit-il que le programme SDL de base fuit la mémoire?

#include <SDL/SDL.h> 

int main(int argc, char** argv){ 


    SDL_Init(SDL_INIT_VIDEO); 
    SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE); 
    SDL_Quit(); 
    return 0; 

}

Compilé avec la commande:

g++ -o test test.cpp -lSDL

Et voici la sortie de valgrind:

[email protected]:~/cpp/tetris$ valgrind --leak-check=full ./test 
==3271== Memcheck, a memory error detector 
==3271== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
==3271== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info 
==3271== Command: ./test 
==3271== 
==3271== 
==3271== HEAP SUMMARY: 
==3271==  in use at exit: 91,097 bytes in 1,258 blocks 
==3271== total heap usage: 14,250 allocs, 12,992 frees, 2,615,177 bytes allocated 
==3271== 
==3271== 10 bytes in 2 blocks are definitely lost in loss record 8 of 134 
==3271== at 0x4024C1C: malloc (vg_replace_malloc.c:195) 
==3271== by 0x4946F04: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4945DA1: _XimEncodeLocalICAttr (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4947195: _XimSetICValueData (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x493FDF1: _XimLocalCreateIC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4922478: XCreateIC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x407AA64: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x407BCBB: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x4069C2A: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x403F9D3: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x403FA36: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x8048658: main (in /home/christian/cpp/tetris/test) 
==3271== 
==3271== 12 bytes in 1 blocks are definitely lost in loss record 12 of 134 
==3271== at 0x4024C1C: malloc (vg_replace_malloc.c:195) 
==3271== by 0x4A3DA8D: ??? 
==3271== by 0x4A3D48C: ??? 
==3271== by 0x4A3D5A4: ??? 
==3271== by 0x4A3DD26: ??? 
==3271== by 0x4A38BC5: ??? 
==3271== by 0x4A38FCD: ??? 
==3271== by 0x40717DD: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x407BDCA: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x4069C2A: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x403F9D3: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x403FA36: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== 
==3271== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 102 of 134 
==3271== at 0x4024D12: realloc (vg_replace_malloc.c:476) 
==3271== by 0x492847E: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492976D: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492AA41: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492B1A4: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x494B4FA: _XlcDefaultLoader (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4933153: _XOpenLC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x49332C2: _XlcCurrentLC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4933761: XSetLocaleModifiers (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x407161D: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x407AD8F: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== by 0x407BCBB: ??? (in /usr/lib/libSDL-1.2.so.0.11.2) 
==3271== 
==3271== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 103 of 134 
==3271== at 0x4024D12: realloc (vg_replace_malloc.c:476) 
==3271== by 0x492847E: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492976D: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492AA41: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x492B1A4: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x494B4FA: _XlcDefaultLoader (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4933153: _XOpenLC (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x493327D: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x4918F20: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x491AF37: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x48F8459: ??? (in /usr/lib/libX11.so.6.2.0) 
==3271== by 0x48F864E: XGetDefault (in /usr/lib/libX11.so.6.2.0) 
==3271== 
==3271== LEAK SUMMARY: 
==3271== definitely lost: 38 bytes in 5 blocks 
==3271== indirectly lost: 208 bytes in 8 blocks 
==3271==  possibly lost: 0 bytes in 0 blocks 
==3271== still reachable: 90,851 bytes in 1,245 blocks 
==3271==   suppressed: 0 bytes in 0 blocks 
==3271== Reachable blocks (those to which a pointer was found) are not shown. 
==3271== To see them, rerun with: --leak-check=full --show-reachable=yes 
==3271== 
==3271== For counts of detected and suppressed errors, rerun with: -v 
==3271== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 93 from 14)

Pourquoi ce programme SDL de base fuite de mémoire ?

Source

2010-01-04 Christian

Il est très probable que la fuite de mémoire se trouve dans la bibliothèque SDL. Mais je ne suis pas sûr de ça. – rogeriopvl

A fait quelques recherches, et a découvert la surface retournée de SDL_SetVideoMode ne doit pas être libérée de l'appelant. J'ai supprimé cette ligne mais je reçois toujours les mêmes résultats de Valgrind. – Christian

Même pour le programme de base "hello world" OpenGL sans le SDL complet, Valgrind me donne des avertissements similaires à l'intérieur des bibliothèques OpenGL. Il est propre, mais je l'ai supposé

La bibliothèque implementors savent ce qu'ils font (probablement la peine préallocation quelques petits tampons statiques, ils ne jamais libérer),
Même s'ils ne sont pas, il est une question fuite de temps qui sera récupérée par le système d'exploitation lorsque le programme se termine,

et n'ont pas perdu beaucoup de sommeil par-dessus.

Source

2010-01-04 02:50:38 user168715

en effet. Et ce n'est pas seulement avec OpenGL, Valgrind m'a toujours montré des fuites que je n'ai pas pu vérifier (par exemple dans pthreads lib). Vous pouvez contourner ce problème en définissant des suppressions pour les fuites qui n'ont rien à voir avec votre programme. – stijn

Que se passe-t-il lorsque vous déchargez la bibliothèque sans terminer le processus et que vous le rechargez: avez-vous réellement une fuite de mémoire ou la mémoire s'est-elle désallouée lors du déchargement? –

Vous ne savez pas ce que vous voulez dire par là, Matthieu. J'ai essayé dynamiquement de charger SDL en utilisant la bibliothèque dl. Je charge la bibliothèque, appelle les mêmes fonctions de base, puis décharge la bibliothèque. Cela entraîne une fuite de mémoire 21 fois plus importante! – Christian

-6

Les singletons sont presque toujours une «fuite» avec des implémentations standard. C'est généralement correct, car normalement, ce n'est pas comme si vous vouliez décharger votre capacité à faire des choses comme imprimer sur la console.

Source

2010-01-04 02:57:31

SDL a définitivement un problème de fuite de mémoire avec SDL_TLSCleanup et SDL_TLSData.

En fait, SDL_TLSCleanup n'est jamais appelée pour le thread principal .

Source

2014-11-17 02:18:16

Chaque SDL_Surface que vous chargez doit être libérée avant l'appel de SDL_Quit(). Pour ce faire, utilisez simplement SDL_FreeSurface (surfaceName) pour libérer la surface que vous avez allouée à la mémoire.

Source

2015-01-10 19:44:02

Pourquoi Valgrind dit-il que le programme SDL de base fuit la mémoire?

Répondre

Questions connexes