Discussion :

[AFKLM]

Bonjour à tous.

Programmant assez peu, je viens juste de découvrir ce forum à l'ambiance visiblement sympa. Je me permets d'en abuser d'entrée de jeu pour poser une question au sujet d'une erreur qui m'est retournée lors d'un malloc().

En lançant un tous petit programme en cours d'écriture, je me prends un

Code :

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

*** glibc detected *** ./recueils: malloc(): memory corruption: 0x0830c8e0 ***

suivi d'une trace de la pile et d'un plan de la mémoire.
L'adresse donnée correspond à une zone du "heap".

J'ai lu sur le net que ce genre de messages peut apparaître lorsqu'on essaye de libérer deux fois la même zone mémoire par exemple.

Après suivi avec un outil de debuggage, il s'avère que l'appel qui produit cette erreur est un malloc tout simple. CE malloc précis a déjà été exécuté plusieurs fois dans le déroulement du programme ; il crée un élément de liste chaînée simple (ne pas se laisser abuser par le "tree" dans le nom de structure).

Je ne comprends pas pourquoi l'appel fonctionne plusieurs fois puis d'un coup il plante. Et pourquoi je ne reçois pas simplement un NULL de la part de malloc, que je puisse gérer proprement.

Voici le code qui merdouille. Le malloc est au début, facile à voir.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
dirTreeElement *dirTreeNew(void)
{
  dirTreeElement *result;
  result = malloc(sizeof(dirTreeElement));
  if(result != NULL)
  {
    result->next = NULL;
    result->humanName = NULL;
    result->fullPath = NULL;
    result->type = BOOKLET_NONE;
  }
  return result;
}

Le type est défini ainsi :

Code :

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

1
2
3
4
5
6
typedef struct{
  void *next;
  char * humanName;
  char * fullPath;
  int type;
} dirTreeElement;

Je ne comprends pas ce que je fais de travers.

Pour info, ce bout de code fait partie de la partie "utile" d'un tout petit utilitaire avec une interface GTK. Je ne sais pas si la présence de GTK a des effets secondaires ; ça m'étonnerait mais on ne sait jamais...

Je vous remercie pour toute info ou lien qui pourrait m'aider à comprendre ce qui arrive.

AFKLM

[nicolas.sitbon]

Avec si peu de code difficile de dire quoique ce soit néanmoins comme tu parles de GTK+, je tiens à rappeler de ne pas mélanger le malloc de la libc et celui de gtk (g_malloc).
Cordialement.

[AFKLM]

Bonjour.

Ce code ne mélange pas de malloc et de g_malloc sur les mêmes sutructures de données. Par contre, il y a évidemment implicitement ailleurs dans le programme des g_malloc utilisés pour les objets GTK par GTK lui-même. Est-ce celà qui peut entraîner des problèmes ?

Le reste du code ne présente pas franchement d'intérêt pour comprendre le problème... Cette petite procédure est appelée par une boucle qui liste les sous-répertoires du répertoire courant, et appelle une procédure qui va y chercher certains fichiers. Pour les tests j'ai retiré cet appel "browseSubDir". Le problème survient encore. Comme je l'ai dit plus haut, il se produit au moment du malloc dans dirTreeNew.


Oui je sais le code est très sale C'est un peu trop vite fait, puis rebricolé un coup par dessus, mais vu la petitesse de l'application je n'ai pas cherché à faire un truc bien carré.

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
dirTreeElement * buildDirTree(char * baseDirName)
{
   DIR * baseDir;
   DIR * subDir;
 
   char subDirName[2000]; 
 
   struct dirent *entry; 
 
   dirTreeElement *first;
   dirTreeElement *current;
 
   if((baseDir = opendir(baseDirName)) == NULL)
       return NULL;
 
   first = dirTreeNew();    
   current = first;
 
   while((entry = readdir(baseDir)) != NULL)
       {
         if(strcmp(entry->d_name,".") && strcmp(entry->d_name,"..") && entry->d_type==DT_DIR)
         {
            strcpy(subDirName,baseDirName);
            strcat(subDirName,"/");
            strcat(subDirName,entry->d_name);
            subDir = opendir(subDirName);
 
            if(subDir != NULL)
              { 
                current->humanName = makeHuman(entry->d_name);
                current->type = BOOKLET_FOLDER;
                current->next = dirTreeNew();
                current->fullPath = malloc(strlen(subDirName)+1);
                strcpy(current->fullPath,subDirName);
 
                current = current->next;
                //   browseSubDir(subDir,subDirName, &current);
                closedir(subDir);
              }
 
 
         }
       }
      closedir(baseDir); 
      return first;
}

[AFKLM]

Encore moi.
J'ai passé toutes les allocations en g_malloc et g_new, et pareil pour la libération de mémoire. Le problème persiste. Je commence à me poser des questions sur la glibc ou sur glib. Doit y avoir un truc gros comme une maison que je ne vois pas...

Pourquoi l'allocation d'une structure aussi petite fonctionne 22 fois et pas la 23 ème ??

[souviron34]

Pourquoi l'allocation d'une structure aussi petite fonctionne 22 fois et pas la 23 ème ??

Comportement indéterminé ça peut être 250000 fois, ou 1, ou 5... ça dépend de ce que tu écrases dans la mémoire...

Plus prosaiquement, ça me semble un peu étrange ta manière de créer un premier élément... Et ta manière globale de ton algo...

Soit tu veux stocker le basedir (ce que tu ne fais pas, tu ne fais qu'allouer un élément, que tu remplis avec le suivant), soit tu veux réellement stocker ton current directory, et là le new n'est pas bien placé.. Et en plus tu met le next avec une nouvelle structure vide...


Reprenons en pseudo-code l'algo :

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
First est NULL
 
Si peut pas ouvrir base
     sort
Sinon
    Tant qu il y a des entrées
          Si entrée valide
               Crée nouvelle structure
               next est NULL
               Si First est NULL
                   First = structure
               Fin si
          Fin si
    Fin tant que
Fin si

Il me semble pas que c'est compliqué.. Mais ce n'est pas ce que tu as écris..

Et je soupçonne fortement que ce soit la cause (tu as des structures, dans ton cas la dernière, dont les pointeurs ne pointent sur nulle part (et en plus ils ne sont pas initialisés à NULL, d'où le plantage n'importe où...).