realloc(): invalid next size

**Bktero** · 31/01/2012, 17h05

Bonjour,

J'aime pas ça mais je vais demander de l'aide

J'ai fait une fonction qui prend deux paramètres :

nom d'un repertoire (type char*)
"tableaux" pour lister le contenu (type char***)

La fonction lit le contenu du dossier spécifié dans le paramètre 1. Si c'est un fichier régulier ou un dossier (autre que . et ..), elle inscrit son nom dans le "tableau" pointé par le 2e paramètre.

En début de fonction, je fais donc un malloc sur le contenu du 2e argument et si besoin je fais un réalloc dessus (s'il y a "beaucoup" de fichiers). Il s'avère que ce procédé de réallocation me renvoie l'erreur indiqué dans le titre : realloc(): invalid next size. Cette erreur ne survient pas à la première réallocation. Selon la taille du malloc initial, ca peut planter à la 2e ou la 4e... Google ne m'a pas permis de trouver de réponse helpfull.

Voici le code la fonction :

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
 
int repLister(const char *nomRepertoire, char ***listeFichiers)
{
    DIR *repertoire = NULL;
	struct dirent *entite = NULL;
	int indice=0; // ne s'incremente que pour les fichiers affiches
	int taille=3;
 
	// Ouverture du dossier
	if(NULL== (repertoire=opendir(nomRepertoire)) )
	{
	    perror("Impossible d'ouvrir le dossier");
	    return -1;
	}
 
	// Allocation dynamique de la liste ; elle sera agrandie si besoin
    if(NULL == (*listeFichiers=malloc(taille*sizeof(char*))))
    {
        perror("Impossible d'allouer la memoire pour la liste");
	    return -2;
    }
 
    // Lister les elements + affichage
	while( (entite=readdir(repertoire)) )
	{
        if( ((entite->d_type==DT_REG) || (entite->d_type==DT_DIR))
                && strcmp(entite->d_name, ".")!=0
                && strcmp(entite->d_name, "..")!=0 )
        {
 
            if(NULL == (*((*listeFichiers)+indice) = malloc(strlen(entite->d_name)) ) )
            {
                perror("Impossible d'allouer la memoire un element de liste");
                return -2;
            }
 
            strcpy( *((*listeFichiers)+indice), entite->d_name);
 
            printf("%d : %s%s\n", indice, (entite->d_type==DT_DIR) ? "(dir) " : "", entite->d_name);
            indice=indice+1;
        }
        else
        {
            // Ne rien faire pour les fichiers speciaux
            // ainsi que pour les dossiers . et ..
        }
 
        // Liste pleine ?
        if(indice==taille)
        {
            taille=taille*2;
            printf("\tReallocation dans repLister avec taille = %d\n",taille);
            if(NULL == realloc(*listeFichiers, taille*sizeof(char*)))
            {
                perror("Impossible de reallouer la memoire pour la liste");
                return -2;
            }
        }
	}
	return indice;
}

Merci du coup de main !

**Bousk** · 31/01/2012, 17h41

Bonjour,

je n'ai jamais utilisé realloc, mais un malloc me semble suspect

Code :

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

if(NULL == (*((*listeFichiers)+indice) = malloc(strlen(entite->d_name)) ) )

Ne manque-t-il pas un caractère pour contenir le \0 ?

**diogene** · 31/01/2012, 18h04

- La remarque de Bousk est judicieuse, il manque un byte dans l'allocation du malloc()

- Il y a une fuite mémoire en cas d'échec de la réallocation : realloc ne s'emploie pas de cette façon, mais suivant le schéma

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 p = realloc(q,...)
 if(p== NULL)
 { 
    // il y a une erreur. Si on veut récupérer
    // la mémoire précédemment allouée
    free(q);
    // etc...
 }
 else
 {
   q = p;
   // suite du traitement
 }

**Bktero** · 31/01/2012, 20h08

Hey !

@Bousk : bien vu. Je me demande d'ailleurs comment ça peut m'afficher correctement mes chaines... De la chance que la zone possède des 0 partout ? J'ai essayé sous MacOS ce soir (au boulot, j'étais sous Ubuntu), même effet. J'ai rajouté le +1 pour l'allocation.

@diogene : OK. J'ai mis un place un tel mécanisme et ça marche. Je n'ai plus le soucis. Hasard ou cause/conséquence ? Je ne vois pas pourquoi ça marcherait quelques fois mais pas les fois suivantes ?

**Sve@r** · 31/01/2012, 23h13

Envoyé par Bktero

Bonjour,

J'aime pas ça mais je vais demander de l'aide

J'ai fait une fonction qui prend deux paramètres :

nom d'un repertoire (type char*)
"tableaux" pour lister le contenu (type char***)

...

Code :

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

1
2
3
4
5
6
7
8
9
10
int repLister(const char *nomRepertoire, char ***listeFichiers)
{
	DIR *repertoire = NULL;
...
	// Ouverture du dossier
	if(NULL== (repertoire=opendir(nomRepertoire)) )
...
	if(NULL == (*listeFichiers=malloc(taille*sizeof(char*))))
...
}

Merci du coup de main !

Salut

Tu remarques que ton tableau en 2D nécessite une indirection supplémentaire pour être modifié dans la fonction. Ce qui amène ce triple étoile pas évident ensuite à gérer.

Alors que si tu places ton tableau dans une structure, tu déplaces l'indirection sur la structure (qui reste à une étoile) ce qui devient de suite plus simple.
De plus, la structure te permet d'embarquer d'autres éléments qui vont avec, comme par exemple ton nom de répertoire. Bref tu peux mieux maintenir ton code

Exemple

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
typedef struct {
    char *nom;
    char **listeFichiers;
} t_dir;
 
int repLister(t_dir *dir)
{
	DIR *repertoire = NULL;
	...
 
	// Ouverture du dossier
	if(NULL== (repertoire=opendir(dir->nom)) )
...
	if(NULL == (dir->listeFichiers=malloc(taille*sizeof(char*))))
...}

**Bktero** · 01/02/2012, 12h00

L'idée d'une structure n'est pas bête, merci. J'ai peu codé en quick and dirty pour faire un test. Si je décide à développer vraiment le programme, je ferais sûrement des structures pour embarquer dans une seule variables informations utiles.

Personne n'aurait une explication quant à mon poste précédent svp ? ^^

**diogene** · 01/02/2012, 12h12

Je ne vois pas pourquoi ça marcherait quelques fois mais pas les fois suivantes ?

C'est le propre d'un comportement indéfini. Tout dépend de ce qui se trouve dans le byte suivant l'allocation et que tu écrases allégrement par un 0.
Tu as la chance que cette erreur ait été diagnostiquée par le système de temps en temps. Le programme aurait pu sembler marcher pendant des jours, des semaines, avant de planter inopinément.

**Bktero** · 01/02/2012, 14h41

Ton message sous-entend que c'est le mauvais strlen qui serait à l'origine du problème ?

Pourtant, le problème disparaît quand je modifie le realloc. Ajouter ou enlever le +1 à mon strlen ne semble pas avoir d'effet (sauf sur un caractère d'affichage).

**diogene** · 01/02/2012, 15h05

Il y a deux choses :

- sur le malloc, il manque un +1 parce que le strlen ne compte pas le zéro terminal. L'avoir oublié amene un comportement indéfini

- sur le realloc, dans ton premier code, tu ne tiens pas compte que le realloc peut déplacer les données et lorsqu'il le fait, l'ancien pointeur (l'ancienne adresse des données) est invalidé. Le programme plantera alors dès que tu voudras utiliser cette adresse.

**Bktero** · 01/02/2012, 15h20

Oh ! Je croyais que le pointeur passé en paramètre était modifié et qu'après l'exécution de realloc, il pointait sur le nouvel espace mémoire !

J'avoue que si tel avait été le cas, l'argument aurait été un pointeur sur pointeur.

Tout s'explique ! Merci beaucoup !!!

realloc(): invalid next size

C

Discussions similaires

Partager

Partager