¿Por qué Valgrind dice que el programa SDL básico está perdiendo memoria?

Aquí es el programa SDL:¿Por qué Valgrind dice que el programa SDL básico está perdiendo memoria?

#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; 

}

Compilado con el comando:

g++ -o test test.cpp -lSDL

Y aquí está la salida 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)

memoria ¿Por qué se está escapando de este programa SDL básico ?

Fuente

2010-01-04 Christian

es muy probable que la pérdida de memoria se encuentre en la biblioteca SDL. Pero no estoy seguro de eso. – rogeriopvl

Hizo algunas investigaciones, y descubrió que la superficie devuelta desde SDL_SetVideoMode no debe liberarse de la persona que llama. Eliminé esa línea pero todavía obtengo los mismos resultados de Valgrind. – Christian

Incluso para el programa básico de OpenGL "hello world" sin el SDL completo, Valgrind me ofrece advertencias similares en las bibliotecas de OpenGL. Es curioso, pero he asumido

Los implementadores de la biblioteca saben lo que están haciendo (probablemente preasignar algunos pequeños amortiguadores estáticos que nunca se molestan en libres),
Incluso si no lo hace, es una pregunta - pérdida de tiempo que será reclamada por el sistema operativo cuando finalice el programa,

y no haya perdido mucho sueño sobre ella.

Fuente

2010-01-04 02:50:38 user168715

de hecho. Y no es solo con OpenGL, Valgrind siempre ha estado mostrándome fugas que no pude verificar (por ejemplo, en pthreads lib). Puede evitar esto configurando supresiones por fugas que no tienen nada que ver con su programa. – stijn

¿Qué sucede cuando descarga la biblioteca sin terminar el proceso y luego lo vuelve a cargar? ¿Tiene realmente una pérdida de memoria o la memoria se desasoció en la descarga? –

No estoy seguro de lo que quieres decir con esto, Matthieu. He intentado cargar dinámicamente SDL usando la biblioteca dl. Cargué la biblioteca, llamo a las mismas funciones básicas y luego descargo la biblioteca. ¡Esto da como resultado una pérdida de memoria 21 veces más grande! – Christian

-6

Los Singleton son casi siempre una 'fuga' con implementaciones estándar. Sin embargo, normalmente está bien, ya que normalmente no es como si quisiera descargar su capacidad de hacer cosas como imprimir en la consola.

Fuente

2010-01-04 02:57:31

SDL definitivamente tiene un problema de pérdida de memoria con SDL_TLSCleanup y SDL_TLSData.

De hecho, SDL_TLSCleanup nunca se llama para el principal hilo.

Fuente

2014-11-17 02:18:16

Cada SDL_Surface que cargue debe liberarse antes de la llamada de SDL_Quit().

Para hacer esto, simplemente use SDL_FreeSurface (surfaceName) para liberar la superficie que asignó en la memoria.

Fuente

2015-01-10 19:44:02

¿Por qué Valgrind dice que el programa SDL básico está perdiendo memoria?

Respuesta

Cuestiones relacionadas