Discussion :

[FloBaoti]

Salut à tous,

Alors voilà je démarre un peu le C++, et je me retrouve face à une erreur que je ne comprend pas.

J'ai une fonction qui est lancée dans un thread (pthread), que voilà :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
static void *client (void *p_data)
{
   struct cli *p_cli = reinterpret_cast<struct cli*>(p_data);
 
   if (p_cli != NULL)
   {
      // Traitements ...
 
      free (p_cli);
 
   }
}

Avec ces définitions :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
typedef int SOCKET;
typedef struct sockaddr_in SOCKADDR_IN;
typedef struct sockaddr SOCKADDR;
 
struct cli
{
   pthread_t thread;
   SOCKADDR_IN sin;
   SOCKET sock;
   int err;
};

Lorsque le free(p_cli) est exécuté, j'ai droit à cette erreur :

Code :

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

1
2
*** glibc detected *** free(): invalid next size (fast): 0x0804b008 ***
Abandon

Je ne comprend pas trop d'où ça peut venir...

Le p_data en paramètre est défini comme ceci dans la fonction qui lance le thread :

Code :

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

struct cli *p_cli = (struct cli *) malloc (sizeof (p_cli));

et passé ainsi en argument de pthread_create :

Code :

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

pthread_create (&p_cli->thread, NULL, client, (void *)p_cli);

J'utilise les éléments de ma structure dans ma fonction client, et à priori ça fonctionne.

Je ne suis pas du tout familié de tout ce qui est gestion de la mémoire, j'utilise généralement des langages qui gèrent ça eux mêmes, et là je suis un peu perdu.
Je sais qu'étant donné qu'un thread est lancé, il me faut gérer la mémoire sinon il ne libère pas la mémoire qu'il occupe lorsqu'il s'arrête. Mais je ne comprend pas cette erreur...

Si quelqu'un pouvait m'éclairer ça serait cool

Merci par avance en tous cas !!

A+
Flo

[FloBaoti]

Et bien en fait, j'ai trouvé

Il faut absolument bannir le malloc en C++ !!

J'ai remplacé

Code :

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

struct cli *p_cli = (struct cli *) malloc (sizeof (p_cli));

par

Code :

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

struct cli *p_cli = new cli();

Et tout fonctionne !!

Edit: euh en fait c'est moi le b****t ! C'était sizeof(cli) au lieu de sizeof(p_cli) ! Ca passait aussi...

[Goten]

Ca n'empêche qu'il faut bannir le couple malloc/free en C++.. La raison numéro 1 est que malloc n'appelle pas le constructeur de l'objet...

[ram-0000]

Même problème que ici avec en plus les explications : Malloc et Structure

[FloBaoti]

Effectivement c'est entre autres ce topic qui m'a aidé

[FloBaoti]

Par contre, trouvez-vous normal que ce free() ne libère aucun espace en mémoire ?
Un "ps" après que le thread soit arrêté (et donc le free() exécuté) indique la même consommation mémoire pour le processus que lorsque le thread tournait...

Normal ou pas normal ?

[nicroman]

si cli est une struct C, appeler malloc ou new ne change rien...
tant que tu appeles bien delete pour un new, et free pour un malloc !

Maintenant... je veux pas dire de betise mais:

Code :

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

1
2
 
struct cli *p_cli = (struct cli *) malloc (sizeof (p_cli));

est erroné.... et alloue une taille de... pointeur !
sizeof(struct cli) ?

[FloBaoti]

si cli est une struct C, appeler malloc ou new ne change rien...
tant que tu appeles bien delete pour un new, et free pour un malloc !

Effectivement, un delete plutot. Cela dit, ça ne change rien, l'espace mémoire utilisé par le processus ne diminue pas lorsqu'un thread s'arrête...

Faut-il absolument définir le destructeur dans ma classe ? Ou est-ce qu'il y en a un par défaut ?

Maintenant... je veux pas dire de betise mais:

Code :

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

1
2
 
struct cli *p_cli = (struct cli *) malloc (sizeof (p_cli));

est erroné.... et alloue une taille de... pointeur !
sizeof(struct cli) ?

Effectivement j'ai vu ma boulette dans un message au dessus...

[3DArchi]

Faut-il absolument définir le destructeur dans ma classe ? Ou est-ce qu'il y en a un par défaut ?

C++ prévoit un destructeur par défaut si tu n'en proposes pas. Tu ne dois pas définir de destructeur dans ta classe sauf les 2 cas suivant :
1/ Ton destructeur n'est pas trivial, i.e. il ne fait pas rien. En général, on a une ressource à libérer dans le destructeur. Mais, il faut se demander pourquoi on n'utilise pas le RAII (sauf bien sûr s'il s'agit d'une classe RAII).
2/ Ta classe/structure sert de base à un héritage :
2.1/ Elle peut être utilisée de façon polymorphe : le destructeur doit être virtuel et public :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
struct A
{
public:
  virtual ~A();
};
struct B : public A
{
   virtual ~B();
};
 
// Quelque part dans le code tu as des pointeurs A* qui pointent sur des B

2.2/ Elle est bien utilisée dans le cadre de l'héritage, mais pas de façon polymorphe : le destructeur doit être non virtuel et protégé.

Code :

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

1
2
3
4
5
6
7
8
9
10
struct A
{
   protected :
   ~A(){}
};
 
struct B : public A
{
 
};

Pour le 2/ cf ici, et en particulier Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

[FloBaoti]

Ok merci beaucoup pour ces explications

Et donc ça te parait "normal" que la mémoire ne semble pas libérée lors d'un delete dans mon cas ?

[3DArchi]

Et donc ça te parait "normal" que la mémoire ne semble pas libérée lors d'un delete dans mon cas ?

C'est différent. Pour plusieurs raisons :
1/Théorie : si free/delete échoue parce que le pointeur n'est pas valide, tu as un comportement indéterminé. Donc effectivement la mémoire peut ne pas être libérée;
2/Pratique: tu n'as pas le bon thermomètre Sous windows par exemple, la consommation mémoire de ton processus peut ne pas baisser non pas parce que la mémoire n'a pas été libérée, mais tout simplement parce que l'O.S. ne la récupère pas tant qu'il n'en a pas besoin. C'est un peu plus subtile mais tu ne peux pas te fier à la 'consommation mémoire' indiquée dans le gestionnaire de tâche pour en déduire si ta mémoire est libérée ou non.

[FloBaoti]

C'est différent. Pour plusieurs raisons :
1/Théorie : si free/delete échoue parce que le pointeur n'est pas valide, tu as un comportement indéterminé. Donc effectivement la mémoire peut ne pas être libérée;
2/Pratique: tu n'as pas le bon thermomètre Sous windows par exemple, la consommation mémoire de ton processus peut ne pas baisser non pas parce que la mémoire n'a pas été libérée, mais tout simplement parce que l'O.S. ne la récupère pas tant qu'il n'en a pas besoin. C'est un peu plus subtile mais tu ne peux pas te fier à la 'consommation mémoire' indiquée dans le gestionnaire de tâche pour en déduire si ta mémoire est libérée ou non.

Ok, tu sais si Linux gère de la même façon ?

Théoriquement si je n'ai aucune erreur, l'objet est bien détruit et la mémoire remise à disposition ? Même si effectivement la valeur indiquée par un "ps" ne change pas...

[Médinoc]

Aussi, pour un objet assez petit, l'OS ne verra pas la différence, car un processus gère la mémoire par pages. Si deux objets tiennent dans une page et qu'un seul est libéré, l'espace sera disponible pour un autre objet du même processus mais la page ne sera pas rendue au noyau...

[koala01]

si cli est une struct C, appeler malloc ou new ne change rien...
tant que tu appeles bien delete pour un new, et free pour un malloc !

Je mettrais une légère nuance dans le fait que new fait plus que malloc et que... delete fait également plus que free

Ainsi, invoquer new te permet que d'assurer que le constructeur de l'objet est appelé, ce qui permet d'avoir un pointeur pointant directement sur une variable qui se trouve dans un état cohérent (les valeurs des différents membres sont clairement déterminées, au lieu d'être les "crasses" dues à une utilisation antérieure de la mémoire)

De même, invoquer delete au lieu de free permet de t'assurer que le destructeur de l'objet est bel et bien appelé...

Cela n'a pas énormément d'importance si l'ensemble des membres de ta structure sont des objets et non des pointeurs, mais, si ton destructeur n'est pas trivial (parce qu'il doit justement libérer dynamiquement de la mémoire allouée dynamiquement), free occasionnera une fuite mémoire de par le simple fait que le destructeur n'est pas appelé...

Moralité: il est préférable de proscrire malloc et free en C++, à moins que tu ne veuille jouer avec le "placement new" qui est une technique, certes très utile, mais qu'il ne faut utiliser qu'à bon escient