Discussion :

[Mr Light]

Bonjour à tous.

J'ai un problème assez inexpliqué, le programme s'arrete abruptement
sur un stack smashing detected.
M'étant renseigné, j'ai compris que ce terme signifie qu'on a écrasé une zone
en mémoire qu'on n'aurait pas du...
Par contre pas moyen de comprendre pourquoi mon code persiste à le faire.

L'idée du code : Lire dans un fichier en mode binaire, deux structures
contenant des champs de type int et short (il s'agit de fichier bitmap
et des structures INFOHEADER et FILEHEADER, mais ca n'a pas d'importance ici).
Pour ca pas de problème, j'ai fait un essai et ca marchait très bien !
Mais mon code était plus du C que du C++.
J'ai donc voulu obtenir un code plus propre, plus objet, en créant une classe BmpEnTete. Elle contient deux attributs, de type struct INFOHEADER et struct FILEHEADER. J'ai créer un constructeur qui prend en paramètre un nom de fichier, et j'ai mis dedans exactement le code que j'avais pour la lecture et qui MARCHAIT.
Et maintenant ca foire...
J'ai isolé le problème avec des cout, le constructeur s'exécute bien jusqu'a
la dernière ligne, et dès qu'on "revient" dans le main, crack !

Je ne sais pas si cela a une importance, je suis sous Linux-Ubuntu.

Quelqu'un a une idée qui lui saute au visage ?

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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
 
#pragma pack( push,1 ) // OBLIGATOIRE ! Empeche le compilateur d'aligner
#include <fstream>
#include <iostream>
#include <cstdlib>
#include <string>
 
using namespace std;
 
 
/* LA STRUCTURE DU PREMIER EN-TETE */
 
struct BMPFILEHEADER 
{
	short bfType; 
	int bfSize ;		
	short bfReserved1 ;
	short bfReserved2 ;
        int * bfOffBits ;
 
};
 
 
/* LA STRUCTURE DU SECOND EN-TETE */
struct BMPINFOHEADER
{
 
	int biSize;
	int biWidth;
	int biHeigth;
	short biPlanes;
	short biBitCount;
	int biCompression;
	int biSizeImage;
	int biXpelsPerMeter;
	int biYpelsPerMeter;
	int biClrUsed;
	int biClrImportant;
};
 
 
 
 
 
 
 
class BmpEnTete
{
	private:
		BMPFILEHEADER fh;
		BMPINFOHEADER ih;
 
	public:
 
		BmpEnTete() {} ;		// Par défaut
 
 
		BmpEnTete(char * nom_fichier, bool & succes) {	// A partir d'un nom de fichier
 
			ifstream FileIn;
			succes = true;
 
			FileIn.open(nom_fichier, ios_base::binary);
 
			if ( FileIn.is_open() ) {
				FileIn.read( reinterpret_cast<char*>(&fh), sizeof(BMPFILEHEADER) );
 
				FileIn.read( reinterpret_cast<char*>(&ih), sizeof(BMPINFOHEADER) );
 
				/* Le nombre de caractère lus par la derniere opération est-t-il correct ? */
				succes = ( FileIn.gcount()  == sizeof(BMPINFOHEADER) ); // Bien passé ? 
 
				FileIn.close();
 
			} else succes = false;
			cout << "fin constructueur" << endl;
 
			return;
		}
 
 
 
		short get_bfType() {
			return fh.bfType;
		}
 
		int get_bfSize() {
			return fh.bfSize;
		}
 
};
 
 
int main(int argc, char * argv[])
{
 
  int taille;
  bool succes;
 
  	BmpEnTete en_tete(argv[1], succes);
 
	cout << "apres construction" << endl;
 
	if (succes) {
		taille = en_tete.get_bfSize();
  		cout << "taille du fichier : " << taille << endl;
	}
  	else 	cout << "l'ouverture du fichier a échouée" ;
 
  return EXIT_SUCCESS;
}

Voila. Ca écrit bien "fin constructeur", puis stack truc...
Je précise que même en commentant les lignes FileIn.read... (et le .gcount()), enfin en gros en ne gardant que l'ouverture/fermeture du fichier l'erreur reste la même. Ce n'est donc aucunement un problème lié à la lecture même dans le fichier.

[babar63]

D'après le code envoyé il n'y a pas de

Code :

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

#pragma pack( pop )

à la fin de ton fichier... Aussi il me paraitrait plus logique de placer le

Code :

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

#pragma pack( push, 1)

après les includes de tes fichiers. Je ne vois pas d'autre problème si ça ne vient pas de là...

[screetch]

Et si tu commentes tout le code ?
et sais tu si ca passe par la premiere ou la deuxieme branche du if ? (le fichier a t'il ete trouvé ?)
que vaut argv[1] ?

[screetch]

ah oui le pragma push est global et ca ce n'est pas bon du tout! il faut le mettre seulement pour tes structures sinon tu fais de meme avec les structures de la stl

[Mr Light]

J'étais loin de penser à ça...
Ca marche très bien ! BitMaps gare à vous !
Merci beaucoup !

[Médinoc]

AU passage, je rappelle que les BITMAPFILEHEADER sont censées être en pack 2, pas 1...

Quant aux BITMAPINFOHEADER, elles ne sont pas packed du tout.

[Mr Light]

Pour la structure BITMAPFILEHEADER je suis daccord pour le pack 2 plutot que 1, elle ne contient en effet que des int ou des short.
Par contre pour la structure INFOHEADER que veux tu dire par pas packed du tout ? Cette structure contient également des short et des int, mais ils sont tous alignés sur le disque. Si je veux pouvoir faire des transferts disque<->mémoire directement, je dois donc bien l'aligner sur 2 non ? Je constate que ca marche en tout cas.

[Médinoc]

Elle n'est pas entourée de pragma pack() dans les fichiers d'en-tête, donc je suppose qu'elle est alignée naturellement sur ce qui doit être 32 bits.

On constate d'ailleurs que les deux seuls WORD sont l'un à côté de l'autre, entourés de valeurs 32 bits partout. On peut donc supposer qu'il n'y a aucun padding dans cette structure, même avec un alignement sur 32 bits.

[Mr Light]

Effectivement cela revient sans doute au même.
Dans quels fichiers d'en-tête l'as tu aperçu ? Parce que je bosse sur les bmp en bas niveau pour un projet scolaire, et pour l'instant j'ai tout tapé en partant de rien. Je serais heureux de consulter un code extérieur.

[Médinoc]

J'ai trouvé ces structures dans le wingdi.h du SDK Microsoft (mais elles doivent être pareilles dans celui de MinGW, à part les #pragma pack remplaçés par des __attribute__((packed)) sur les structures elles-mêmes).