Discussion :

[plumedesiles]

Bonjour à tous,,
Je poste après avoir cherché longuement sur le net une réponse à mon problème.

J'ai écrit un petit programme qui se charge de lancer un thread au démarrage puis il alloue des matrices, tableau 2d. Un petit calcul de sommation est ensuite réalisé, puis les matrices sont désallouées. Hors quand je regarde un top ou un moniteur système la mémoire n'est pas effectivement libérée.

J'ai pratiqué plusieurs tests. Le premier est de ne pas lancé le thread et d'utiliser mtrace pour voir s'il n'ya pas de fuite mémoire. Réponse y en a pas.
La mémoire est également bien libérée sans lancer le thread.

Lorsque je procéde à un autre test en lancant cette fois-ci le thread, la mémoire est bien désallouée puisque si le programme refait une allocation il ne demande pas de mémoire supplémentaire au système. Par observation avec top. Par contre si je ne désalloue pas la mémoire et demande une réallocation à ce moment là, j'ai une fuite mémoire puisque de nouvelles ressources mémoires sont pris au système

J'ai également essayé sur d'autres plateformes, d'autres compilateurs, d'autres noyaux. Sur ces autres plateformes, la mémoire est bien rendu au système.
Après réflexion, la seule différence entre ces plateformes et celle où le problème réside est le 64 bits (plusieurs plateforme de tests en 64bits, en fait). En effet, la mémoire est bien désalloué en 32bits, même sur une plateforme 64bits avec compilation avec gcc -m32.

J'espère avoir été clair et complet. Je joins le bout de code ci-dessous. Soit j'ai fait une erreur fondementale, soit quelque chose m'échappe.

Merci d'avance pour vos laternes

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
 
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
 
void sum(double** A, double **B, int block_size)
{
	int i,j;
 
	for(i=0; i < block_size; i++)
	  for(j=0 ; j < block_size; j++)
		A[i][j]=A[i][j]+B[i][j];
}
 
void read_mat(double ***matrix, int block_size)
{
	int i,j;
 
	*matrix=malloc(block_size*sizeof(double*));
 
	for(i=0; i< block_size; i++)
	{	
		(*matrix)[i]=malloc(block_size*sizeof(double));
		for(j=0; j < block_size; j++)
			(*matrix)[i][j]=1.0;
	}
}
 
void free_mat(double **matrix, int block_size)
{
	int i;
 
	for(i=0; i< block_size; i++)
             free(matrix[i]);
	free(matrix);
 
 
}
 
void * launch(void* pthis)
{
	printf("hoho thread\n");
 
        pthread_exit(0);
}
 
 
 
int main( int argc, char **argv )
{
    int block_size=10000;
    double **A;
    double **B;
    void* status;
    pthread_t th;
 
    pthread_create(&th,NULL,launch,NULL);
 
    printf("Alloc\n");
    read_mat(&A,block_size);
    read_mat(&B,block_size);
 
    pthread_join(th,&status);
 
    sum(A,B,block_size);
 
    printf("%f\n",A[0][0]);
 
    sleep(5);
 
    printf("Clear\n");
    free_mat(A,block_size);
    free_mat(B,block_size);
 
    sleep(5);
 
  pthread_exit(NULL) ;
}

[LittleWhite]

Bonjour,

Chaque problème à son outil.

Pour vérifié les fuites de mémoire, rien de mieux que valgrind.
Ceci est un outil qui regarde toutes vos actions sur la mémoire. Je ne pense pas que mtrace pourrait en faire autant ( surtout en voyant la page du man ).
Donc lancez voir votre programme avec valgrind, et vous verrez surement plein de chose. ( Surtout qu'avec les bonnes options, il arrive à dire ou sont les fuites ).

[plumedesiles]

La sortie de
valgrind --tool=memcheck --leak-check=full a.out

n'indique rien. D'autres options à utiliser peut-être ?
Je ne suis pas super familier avec valgrind

[Fabllot]

Bonjour,

A vue de nez, il y a assez peu de malloc et de free... donc la vérification du code est simple, et il n'y a pas l'air d'avoir de soucis de fuite...

Par contre, je ne suis pas certains de comprendre l'utilité de ton thread... Tu ne fais rien avec !

[ram-0000]

Peut être que la mémoire allouée est effectivement libérée par le process (et donc il n'y a pas de fuite) mais que le système ne rend pas la mémoire au cas où tu ferais une nouvelle allocation. C'est en quelque sorte une espèce d'optimisation (un cache). Ce comportement est totalement dépendant du choix d'implémentation du malloc()/free() et il n'est pas anormal que tu ne puisse le reproduire sur des plateformes différentes.

Juste une idée comme cela.

[plumedesiles]

Ok merci.

Comme je l'ai dit, la mémoire est bien désalloué. Effectivement, j'ai lu quelques papiers sur la NPTL, il y a ce genre d'optimisation qui garde la mémoire allouée. Sauf que celle-ci nést même rendu si le système se retrouve à cours. C'est là où ca devient dangereux.
Pour être plus précis, je réserve jusqu'a 32 GB dans l'application ou ce style de code est utilisé donc il est clairement pas pensable de laisser le système faire.

Il doit bien avoir un moyen de forcer le système. Dans mes derniers tests, j'ai pu voir que la mémoire était désallouée desfois mais c'est alléatoire.
Merci en tout cas pour vos suggestions

[JeitEmgie]

pthread_exit n'a rien à faire dans main…