[SDL_TTF] Utilisation mémoire qui ne cesse d'augmenter

**Halarp27** · 04/03/2014, 09h09

Bonjour, dans un petit programme SDL2 avec SDL_TTF je rend du texte à plusieurs SDL_Texture. Seulement bien que je libère la texture avant de la créer à nouveau l'utilisation de la mémoire augmente toujours.

Mon fichier text.c :

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
#include <SDL2/SDL.h>
#include <SDL2/SDL_ttf.h>
 
#include "context.h"
#include "error.h"
 
SDL_Texture *SDL_Texture_render_text(SDL_Renderer *renderer, TTF_Font *font, 
char const text[], const SDL_Color color)
{
    SDL_Surface *surface = NULL;
    SDL_Texture *texture = NULL;
 
    if((surface = TTF_RenderText_Blended(font, text, color)) == NULL)
        error_ttf();
 
    if((texture = SDL_CreateTextureFromSurface(renderer, surface)) == 0)
        error_sdl();
 
    SDL_FreeSurface(surface);
 
    return texture;
}
 
void GameCtx_render_speed_tex(SDL_Renderer *renderer, GameCtx *game)
{
    char text[20];
    SDL_Color color = {0x0, 0x0, 0x0, 0x0};
 
    if(game->speed == SPEED_MAX)
        sprintf(text, "- Speed : %" PRIu8 " (MAX)", game->speed);
    else
        sprintf(text, "- Speed : %" PRIu8, game->speed);
 
    SDL_DestroyTexture(game->tex->speed);
    game->tex->speed = SDL_Texture_render_text(renderer, game->font, text, color);
 
    SDL_QueryTexture(game->tex->speed, NULL, NULL, &game->rect->speed.w, 
    &game->rect->speed.h);
}
 
void GameCtx_render_score_tex(SDL_Renderer *renderer, GameCtx *game)
{
    char text[512];
    SDL_Color color = {0x0, 0x0, 0x0, 0x0};
 
    sprintf(text, " - Score : %" PRIu32 " -", game->score);
 
    SDL_DestroyTexture(game->tex->score);
    game->tex->score = SDL_Texture_render_text(renderer, game->font, text, color);
 
    SDL_QueryTexture(game->tex->score, NULL, NULL, &game->rect->score.w, 
    &game->rect->score.h);
}

Je ne comprend pas, je libère pourtant bien les SDL_Texture avec SDL_DestroyTexture(), mais pourtant le programme consomme toujours plus de mémoire. Comeent cela se fait-il ? Comment résoudre ce problème ?

**LittleWhite** · 05/03/2014, 09h52

Bonjour,

Comment faites vous pour constater cette fuite de mémoire ?
Pouvez-vous tester avec valgrind, ou Dr Memory

**Halarp27** · 05/03/2014, 17h16

Je regarde simplement la liste des processus, et à la ligne du programme dans l'onglet de la mémoire utilisée, sa consommation augmente à peu près chaque 3 secondes de 0.2 mo.

Sinon j'ai essayé valgrind avec l'option -q, pour qu'il n'affiche que les erreurs :

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
==21743== Conditional jump or move depends on uninitialised value(s)
==21743==    at 0x8730C15: ??? (in /usr/lib/nvidia-319/libGL.so.319.32)
==21743==    by 0xB286EAF: ???
==21743== 
==21743== Invalid read of size 1
==21743==    at 0x401753: GameCtx_set_wall (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x40183C: GameCtx_scrolling (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401940: GameCtx_evolution (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401B26: GameCtx_play_loop (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x4010D1: main (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==  Address 0xc202f7c is 0 bytes after a block of size 12 alloc'd
==21743==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21743==    by 0x401F23: GameCtx_load_grid (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401FA6: GameCtx_create (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x4010C2: main (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743== 
==21743== Invalid read of size 1
==21743==    at 0x401793: GameCtx_set_wall (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x40183C: GameCtx_scrolling (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401940: GameCtx_evolution (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401B26: GameCtx_play_loop (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x4010D1: main (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==  Address 0xc20360c is 0 bytes after a block of size 12 alloc'd
==21743==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21743==    by 0x401F23: GameCtx_load_grid (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x401FA6: GameCtx_create (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==    by 0x4010C2: main (in /home/anonyme/Prog/No_Collision/No_Collision)
==21743==

**LittleWhite** · 05/03/2014, 21h19

Sauf, que si fuite de mémoire il y a, il y a pointeur non désalloué à la fin du programme (souvent) et donc, valgrind l'affiche à la fin de son exécution (si vous quittez le programme assez proprement disons). Veuillez donc réessayer, de plus, il faut compiler le programme avec l'option -g de GCC, pour avoir des détails sur le code et il faut suivre les indications des options de valgrind (il indique des trucs comme --leak=full, je me rappelle jamais, mais comme il indique les options

)

**Halarp27** · 06/03/2014, 09h33

Avec l'option -g en plus lors de la compilation valgrind me renvoie ça :

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
==13978== Memcheck, a memory error detector
==13978== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13978== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13978== Command: ./No_Collision
==13978== 
==13978== Conditional jump or move depends on uninitialised value(s)
==13978==    at 0x8730C15: ??? (in /usr/lib/nvidia-319/libGL.so.319.32)
==13978==    by 0xB286EAF: ???
==13978== 
==13978== Invalid read of size 1
==13978==    at 0x401753: GameCtx_set_wall (game.c:14)
==13978==    by 0x40183C: GameCtx_scrolling (game.c:99)
==13978==    by 0x401940: GameCtx_evolution (game.c:151)
==13978==    by 0x401B26: GameCtx_play_loop (input.c:68)
==13978==    by 0x4010D1: main (main.c:26)
==13978==  Address 0xc20279c is 0 bytes after a block of size 12 alloc'd
==13978==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13978==    by 0x401F23: GameCtx_load_grid (ld_context.c:142)
==13978==    by 0x401FA6: GameCtx_create (ld_context.c:159)
==13978==    by 0x4010C2: main (main.c:24)
==13978== 
==13978== Invalid read of size 1
==13978==    at 0x401793: GameCtx_set_wall (game.c:14)
==13978==    by 0x40183C: GameCtx_scrolling (game.c:99)
==13978==    by 0x401940: GameCtx_evolution (game.c:151)
==13978==    by 0x401B26: GameCtx_play_loop (input.c:68)
==13978==    by 0x4010D1: main (main.c:26)
==13978==  Address 0xc202e2c is 0 bytes after a block of size 12 alloc'd
==13978==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13978==    by 0x401F23: GameCtx_load_grid (ld_context.c:142)
==13978==    by 0x401FA6: GameCtx_create (ld_context.c:159)
==13978==    by 0x4010C2: main (main.c:24)
==13978== 
==13978== 
==13978== HEAP SUMMARY:
==13978==     in use at exit: 68,618 bytes in 470 blocks
==13978==   total heap usage: 16,831 allocs, 16,361 frees, 19,636,006 bytes allocated
==13978== 
==13978== LEAK SUMMARY:
==13978==    definitely lost: 16,465 bytes in 16 blocks
==13978==    indirectly lost: 0 bytes in 0 blocks
==13978==      possibly lost: 0 bytes in 0 blocks
==13978==    still reachable: 52,153 bytes in 454 blocks
==13978==         suppressed: 0 bytes in 0 blocks
==13978== Rerun with --leak-check=full to see details of leaked memory
==13978== 
==13978== For counts of detected and suppressed errors, rerun with: -v
==13978== Use --track-origins=yes to see where uninitialised values come from
==13978== ERROR SUMMARY: 104 errors from 3 contexts (suppressed: 8 from 3)

Sinon j'ai créer un autre petit programme plus court pour voir si j'ai toujours le même problème, et c'est le cas. Voici son main.c :

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
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
#include <stdio.h>
 
#include <SDL2/SDL.h>
#include <SDL2/SDL_ttf.h>
 
#include "context.h"
#include "error.h"
 
SDL_Texture *SDL_Texture_render_text(SDL_Renderer *renderer, TTF_Font *font, 
const char text[])
{
    SDL_Surface *surface = NULL;
    SDL_Texture *texture = NULL;
    SDL_Color color = {0};
 
    if((surface = TTF_RenderText_Blended(font, text, color)) == NULL)
        error_ttf();
 
    if((texture = SDL_CreateTextureFromSurface(renderer, surface)) == 0)
        error_sdl();
 
    SDL_FreeSurface(surface);
 
    return texture;
}
 
int main(void)
{
    ScreenCtx *screen;
    SDL_Event event;
    SDL_Texture *texture = NULL;
    SDL_Rect rect;
    TTF_Font *font = NULL;
    char text[128];
    Uint32 time = 0, curent_time = 0, previous_time = 0;
 
    if(SDL_Init(SDL_INIT_VIDEO) == -1)
        error_sdl();
 
    if(TTF_Init() == -1)
        error_ttf();
 
    screen = ScreenCtx_create("Timer");
    font = TTF_Font_load();
 
    do
    {
        SDL_PollEvent(&event);
 
        SDL_RenderClear(screen->renderer);
 
        if(texture != NULL)
            SDL_RenderCopy(screen->renderer, texture, NULL, &rect);
 
        SDL_RenderPresent(screen->renderer);
 
        SDL_Delay(5);
 
        curent_time = SDL_GetTicks();
 
        if(curent_time - previous_time > 250)
        {
            time += 250;
 
            sprintf(text, "%" PRIu32, time);
 
            if(texture != NULL)
                SDL_DestroyTexture(texture);
 
            texture = SDL_Texture_render_text(screen->renderer, font, text);
            SDL_QueryTexture(texture, NULL, NULL, &rect.w, &rect.h);
 
            rect.x = (SCREEN_WIDTH / 2) - (rect.w / 2);
            rect.y = (SCREEN_HEIGHT / 2) - (rect.h / 2);
        }
 
    }while(event.type != SDL_KEYDOWN);
 
    TTF_CloseFont(font);
    ScreenCtx_free(screen);
 
    TTF_Quit();
    SDL_Quit();
 
    return 0;
}

**LittleWhite** · 06/03/2014, 09h45

En effet, avec ce code, le problème est très visible.
À chaque appel de SDL_Texture_render_text(), vous créez une texture. Cette texture n'est absolument jamais libérée (quel dommage). Du coup, fuite de mémoire.
N'oubliez donc pas le SDL_DestroyTexture().
De plus, en théorie, il faudrait éviter de créer autant de surface/texture. Au maximum, éviter de le faire dans la boucle principale du programme.

De mémoire, ils en parlent dans le guide de migration SDL 1 -> SDL 2 : http://jeux.developpez.com/tutoriels...ation/#LII-B-2

**Halarp27** · 06/03/2014, 11h48

Oui, mais j'ai besoin de retourner la texture, donc je ne peux pas la libérer dans la fonction SDL_Texture_render_text(). Je pensais que je libérez la texture pourtant, puisqu'elle est retournée et que je fait un SDL_DestroyTexture() juste avant d'appeler à nouveau SDL_Texture_render_text().

S'il faudrait en "théorie" éviter de créer autant de surfaces/textures, alors comment faire pour rendre un texte qui change souvent ? Est-ce qu'il serait par exemple pertinant d'allouer tout les pixels de la SDL_Surface créee vers la texture ? Si l'on fait ça la taille de la texture ne changera jamais, et ça peut poser problème.

**LittleWhite** · 06/03/2014, 13h32

Pour la première question, en effet, je n'avais pas vu. Du coup, j'ai du mal à saisir l'origine de la fuite (y en a t-il une, valgrind ne semble pas trop le montrer).
Pour la seconde remarque, dans un tel cas, on utilisera une police bitmap ou (même si c'est pour OpenGL ce second lien, je préfère le montrer, pour information : police bitmap OpenGL Nehe)

**Halarp27** · 06/03/2014, 14h00

Pourquoi utiliser une police bitmap, le format ttf ne convient pas ?

**LittleWhite** · 06/03/2014, 14h06

Le principal défaut (notamment pour le texte dynamique) c'est qu'il y a création d'une surface à chaque affichage du texte.

**Halarp27** · 06/03/2014, 14h24

C'est embêtant de ne pas pouvoir utiliser SDL_TTF pour rendre du texte. C'est pourtant plus avantageux que d'utiliser un format bitmap.
Je pense que pour les ordinateurs actuels le fait de créer une surface à chaque disons 250 millisecondes n'est pas ce qu'il y a de plus gourmant si on libère la surface avant.

Sinon comment fait-on ici pour rendre du texte à un SDL_Texture sans fuite de mémoire ?

**LittleWhite** · 06/03/2014, 17h52

Sauf que rien ne dit qu'il y a vraiment une fuite de mémoire, enfin, pas valgrind.
Toutefois, j'en vois une, mais minime (en effet, la texture n'est pas nécessairement libérée en sortie de boucle (après la boucle)).

**Halarp27** · 06/03/2014, 18h56

Oui, mais je ne comprend pas. Elle devrait normallement ne pas exister, car le SDL_Texture est bien retournée dans un autre SDL_Texture, qui lui même est détruit au prochain tour de boucle. Donc, elle a bien été libérée.

**LittleWhite** · 06/03/2014, 21h00

Pas dans le cas du tout dernière tour de boucle, ou la texture créer n'est pas supprimée, car il n'y a pas de "nouveau passage dans la boucle".
Faites une exécution pas à pas.

Mais bon, cette fuite est petite et ne semble pas correspondre à la fuite remarquée par l'ouvreur du poste. Et comme valgrind ne voit pas le soucis, je pense qu'il n'y a pas de fuite ... ou alors y a un truc qui m'échappe, mais qui m'échappe vraiment

**Halarp27** · 07/03/2014, 18h44

Si vous le dite

En observant le comportement du dernier code, je m'apperçoit que l'utilisation de mémoire finit par se stabiliser après être montée en flèche. Sans doute parce que la texture grossit.

Bon, désolé du dérangement. J'ai maintenant l'impression d'avoir créer un sujet pour rien

**LittleWhite** · 07/03/2014, 20h44

Vraiment, si valgrind ne râle pas sur des fuites, c'est que c'est bon signe. Après, utiliser une outil comme le "moniteur système" ou "gestionnaire des tâches" pour voir une fuite, à part une vraie monté en flèche de votre programme en 100 de méga, c'est dur à dire, car ces outils ne sont pas très très précis (ou ne repose pas sur les données que l'on veut). Donc oui, au lancement + quelques secondes après, il y aura montée, le temps que le moniteur détecte bien l'utilisation mémoire et normalement, pour le reste, rien de plus.
Si c'était une montée continuelle sur plusieurs minutes, valgrind aurait râlé

Bonne continuation.

[SDL_TTF] Utilisation mémoire qui ne cesse d'augmenter [SDL 2.0]

SDL

Discussions similaires

Partager

Partager