Stack smashing lors d'un free()

Salut,

Je transforme un array en tableau deux dimensions, je peux ensuite remplir le tableau avec les données de l'array de base, manipuler les données et enregistrer le résultat dans un fichier sans problème.

Toutefois lors de la libération du tableau apparaît ce problème et qui plante l'appli bien sur.
Le tableau est créé comme ceci:
Les données sont une image, on a donc width et height qui sont ses dimensions en pixels,
chaque pixel est un uint32 pour les quatre composantes RGBA et buffer qui est l'array de base.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

npixels = width * height; offset = npixels - width; length = 4 * width; uint32 *raster[height]; for (row = 0; row < height; row++) raster[row] = malloc(width * sizeof(uint32));   for (row = 0; row < height; row++) { memcpy(raster[row], buffer + offset, length); offset -= width; } _TIFFfree(buffer);   // traitement des données du tableau .....   for (row = 0; row < height; row++) { printf(" %lu", row); free(raster[row]); }

---

Comme mon fichier image était correctement écrit, j'ai supposé que le problème venait de la fin du code, j'ai ajouté le printf(" %lu", row) pour vérifier ça.

Je l'ai aussi testé sans aucune manipulation des données, donc du remplissage du tableau directement au free() avec le même résultat.

Voici la sortie (abregée):

Code:

---

1 2 3

0 1 2 ...... 2676 2677 2678 26*** stack smashing detected *** 79 2680 2681 2682 2683 2684 2685 ....2864 2865 2866 2867Abandon (core dumped)

---

Dans cet exemple, il s'agit d'une image de 2868 pixels de haut, le stack smashing apparaît toujours exactement au même endroit (row 2679) et pourtant il continue jusqu'au bout (row 2867).

J'utilise gcc-4.5.3 sur Linux 64b.

Tu rencontres probablement déjà un dépassement de capacité au premier memcpy : tu initialises length, pourtant tu ne te sers que de npixels et de width pour initialiser et décrémenter offset. Corrige déjà cet UB, on verra ensuite pour le dépassement de pile (possible qu'on ai besoin du reste du code).

Pourquoi recopier ton image dans une série de buffers ? Tu ne veux pas utiliser un seul et unique bloc ? Ce serait bien plus simple et performant : malloc(npixels * 4) .

Heu, il me semble que le troisième argument de memcpy est le nombre de bytes et pas le nombre de uint32 donc length = 4 * width.

Me trompe-je ?

La raison du changement du buffer est que celui-ci est rempli par la lib libtiff et que celle-ci se base sur le pixel inférieur gauche, donc buffer = row n,row n-1,row n-2, etc.
Pour un filtre d'image (par ex contraste ou température de couleur) qui manipule des pixels seuls ça n'a pas d'importance mais pour un filtre dont l'algorithme procède avec les pixels voisins (ex non local means) cette disposition devient casse-tête, la disposition en tableau à l'identique de l'image facilite grandement les choses.

Je réalise après coup ton interrogation, en fait le buffer est initialisé comme ceci:

Code:

---

1 2	buffer = _TIFFmalloc(npixels * sizeof(uint32));

---

après remplissage par libtiff on accède au pixels avec

Code:

---

1 2 3 4 5

r = (int )TIFFGetR(buffer[p]); g = (int )TIFFGetG(buffer[p]); b = (int )TIFFGetB(buffer[p]); a = (int )TIFFGetA(buffer[p]);

---

où p est l'index du pixel soit de 0 à npixels -1, c'est pourquoi offset est décrémenté de width et pas de width * 4

J'ai bien compris mais tu peux justement renverser l'ordre des lignes sans faire une allocation pour chacune.

En ce qui concerne l'adressage, je reformule : la taille d'un élément (sizeof(uint32_t), ou 4) n'intervient pas dans ton calcul d'offset. Tu devrais :

1. l'initialiser comme ceci : offset = (npixels - width) * 4; ;
2. l'ajuster comme ceci : offset -= width * 4; (ou offset -= length;).

EDIT : Ah, si buffer est de type uint32_t * (peu importe comment est réalisée l'allocation), alors effectivement c'est correct. C'est parcequ'il ne me viendrait pas à l'idée d'utiliser autre chose qu'un unsigned char *, déformation professionnelle. :)