Discussion :

[Nekkro]

Bonjour,

Un problème un peu étrange qui vient de m'arriver et dont je n'arrive pas à me défaire :

J'ai un objet d'une classe quelconque, avec une string comme attribut.
Je n'ai pas besoin de remplir cette string tout de suite, je tiens à ce qu'elle reste vide avant de l'initialiser dans une méthode plus tard.
Je considère, avec raison, que le constructeur de cette string sera appelé correctement et qu'un fois mon objet créé, son membre string sera lui aussi considéré comme correct.

Seulement voilà, lorsque dans ma première méthode utilisée je fais !_str.empty() j'ai le droit a un magnifique crash avec erreur 0xC0000005.

Et j'ai ce problème à chaque exécution.
Comment ceci est-il possible ?

[screetch]

poste ton code, sinon on ne peut pas t'aider.
peut-être ton objet a été alloué et déjà desalloué?

beaucoup de noms commencant par underscore sont reservés, il est préférable de les mettre a la fin.

[Nekkro]

Une petite rectification, quelque soit la façon dont je tente d’accéder à ma string, ça plante.

Voici le code simplifié :
.hpp

Code :

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

1
2
3
4
5
6
7
8
class X
{
	void handle_error (const system::error_code & e);
	private:
		string _auth_key;
		bool connected;
		/* ... */
};

.cpp

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
void X::handle_error (const system::error_code & e)
{
	switch (e.value())
	{
		case 10054: // Connexion coupée
			/* ... */
		break;
		case 10061: // Connexion impossible
			if (!connected && !_auth_key.empty()) // Voilà la ligne responsable du crash
			{
				/* ... */
			}
			else
				/* ... */
		break;
		default:
			/* ... */
	}
}

je ne fais vraiment rien de particulier, et comble de l'étrangeté, il y a deux jour ce code marchait parfaitement.

[screetch]

a priori je dirai donc que quelqu'un de mal intentionné (en toute probabilité, toi-même en fait) ecrase de la mémoire quelque part.

Ce que je ferais donc, si tu as un bon debugger (visual studio) c'est de mettre un breakpoint mémoire; pour cela:
* mets un breakpoint (normal) dans le constructeur de X
* lorsque tu vas arriver a ce breakpoint, ajoute un "memory breakpoint"/breakpoint m´emoire sur "&_auth_key"
* continues l'execution et le programme s'arrêtera de lui même a chaque fois que _auth_key est changée

[Nekkro]

Je travaille sous Code::Blocks malheureusement ...

Autre chose que je viens de tester :

Si je transforme la ligne comme ceci :

Code :

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

if (!connected /*&& !_auth_key.empty()*/) // Voilà la ligne responsable du crash

Le programme fonctionne sans problème !

[screetch]

Code::Blocks a aussi des breakpoint mémoire je pense (Data breakpoint), le principe est exactement le même-
bon sinon il y a la méthode de dichotomie, c'est plus long mais ca marche.
ca consiste a ajouter le code _auth_key.empty(); partout partout, surtout dans des boucles et les méthodes appelées souvent, et voir quel est le premier qui pète. Tu sauras alors que l'erreur est intervenue entre le dernier _auth_key.empty() qui n'a pas explosé et celui qui vient d'exploser.

[Nekkro]

C'était une bonne idée, merci, ça m'a permis de voir que ce n'était pas la string qui posait problème ! Le code était beaucoup plus vicelard que ça :

En fait dans mon else, j'utilisais une fonction d'affichage qui elle-même utilisait un équivalent de printf pour mettre en forme. Le problème, c'est que j'envoyais deux arguments pour le formatage alors qu'il n'en attendait qu'un seul !

Voilà donc ce qui posait problème ... Il m'a suffit d'enlever l'argument de trop et tout ceci est rentré dans l'ordre.

[JolyLoic]

La vraie parade consiste à ne pas utiliser de fonctions comme printf qui se comportent mal en cas d'erreur

[Nekkro]

En fait, c'est une fonction d'affichage de ce type :

Code :

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

void print (const char * str, ...);

C'est la seule solution que je connaisse pour formater ce que je veux dans une chaîne de caractère, tout en faisant d'autres vérifications dans le corps de la fonction bien entendu.

C'est donc ma va_list qui me fait planter je crois.

[screetch]

sous GCC il y a un moyen d'activer les warnings de formattage (donc de vérifier que les arguments seront corrects a la compilation)
ainsi que de declarer une fonction "printf-like", pour que GCC applique aussi la verification a cette fonction

http://www.unixwiz.net/techtips/gnu-...es.html#format
et l'option -Wformat

[JolyLoic]

En fait, c'est une fonction d'affichage de ce type :

Code :

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

void print (const char * str, ...);

C'est la seule solution que je connaisse pour formater ce que je veux dans une chaîne de caractère, tout en faisant d'autres vérifications dans le corps de la fonction bien entendu.

C'est donc ma va_list qui me fait planter je crois.

Jette un oeil sur boost.format :

Boost.format enforces a number of rules on the usage of format objects. The format-string must obeys the syntax described above, the user must supply exactly the right number of arguments before outputting to the final destination, and if using modify_item or bind_arg, items and arguments index must not be out of range.
When format detects that one of these rules is not satisfied, it raises a corresponding exception, so that the mistakes don't go unnoticed and unhandled.

[Arzar]

Tiens ça me fait penser à l'excellent article de John Carmarck sur les analyseurs statiques de code.
Dans cette article Carmack explique qu'il a finalement décidé de passer un coup d'analyseur statique sur l'ensemble de la codebase d'ID software et surprise !

Printf format string errors were the second biggest issue in our codebase

J'avoue que je n'en reviens toujours pas.
C'est amusant de voir que lorsque les gens évoquent les difficultés classiques du C, la discussion tourne toujours autour de la gestion manuelle de la mémoire, des dépassements de tableaux, de la gestion manuelle des string (char* + '\0'), ce genre de truc, mais personne ne s'attarde vraiment sur le danger de bête erreur de printf, qui pourtant formerait donc une des classes de bug la plus répandu !