Discussion :

[Hanz Peter Mariol]

Bonjour à tous,

J'ai un petit problème sous windows xp 2002 sp2. J'ai une application en vb.net qui appelle un executable vc++.
A la fin de l'execution de l'appli vcpp (juste avant le return 0
Il arrive que le programme me lance, de manière assez aléatoire, une exception DEP. Comme s'il ne parvenait pas à clore le programme et à repasser à l'IHM.
Auriez vous une idée? je suis dans le floue...

Merci d'avance

[3DArchi]

Un petit problème de débordement dans ton appli vc++?

[Hanz Peter Mariol]

Ouai j'aurais bien dit ca aussi, mais ce qui est amusant, c'est que cela plante vraiment à la toute fin de l'execution, genre quand l'appli vc++ devrait libérer l'espace qu'elle prend, retourner 0 et se fermer.

Le fait est que mon appli traite des fichiers csv, et qu'elle ne bugg ainsi que sur certains qui n'ont pas de différences notables les séparant des autres : ils ne sont pas plus volumineux, ils ont exactement la même mise en page, avec juste une ligne vide à la fin pour arréter le traitement, etc.

Bref je suis vraiment peaumé

[Hanz Peter Mariol]

Re,

Alors, le problème a pu etre palié en rajoutant une grosse phase d'initiation, mon hypothèse (qui, si vous pensez qu'elle est fausse, je vous prierais de me le faire savoir), est que la phase d'initialisation qui traite bon nombre de variables, permet d'allouer en premier lieu un espace mémoire important qui permet aux exigences suivantes d'avoir à leur tour une bonne taille.
Sans exigence init, il arrive que la première ligne soit bien plus courte que la seconde, et comme c'est une boucle for, qui exploite les memes variables en leur donnant plus ou moins d'espace pour stocker les nouvelles valeurs, on arrive peut etre a un débordement.
Voilà, je suis ouvert à tout avis.

Merci d'avance

[Médinoc]

J'ai du mal à saisir le sens de ton message.

L'histoire de DEP, elle ressemble vraiment à un simple débordement de pile dans le main(). As-tu un buffer en variable locale dans ton main() ?

[Hanz Peter Mariol]

Si on peut considérer les string comme buffer de char
Ou bien tout char * comme buffer de char
Alors oui j'en ai tout une tripotée. Mais j'ai vu et revu le programme, et il ne m'est pas apparu d'erreur.
Surtout que les fichiers qui plantent, n'ont vraiment rien de particuliers, à part, peut etre, des tailles de lignes très variées (et encore)
Et puis pourquoi cela planterais au moment ou l'on sort du programme vc++ et pas au moment ou il alloue justement de la mémoire pour ces pointeurs?
Peut etre me trompe-je, mais a mon sens c'est au moment de l'allocation que l'exception devrait etre lancée.
Qu'en penses tu?

[Médinoc]

Une std::string n'est pas "un buffer dans la pile" puisqu'elle alloue son buffer dans le tas (sauf pour des chaînes très courtes, mais normalement de toute façon, on n'est pas censé écrire directement dans le buffer d'une std::string. Tu ne fais pas ça, n'est-ce paaaaaaaaaaaaaaas ?
Pour ton histoire de char*, pareil: seuls les buffers dans la pile peuvent causer une erreur au retour de fonction...

[Hanz Peter Mariol]

Mais donc, si possible, puis je avoir un exemple de truc que tu mets dans le buffer de la pile? Que je sache si j'en ai.
Parceque globalement ma méthode principale sont des pointeurs , variables typiques, et autres petits objets nécessaire à ma solution que je manie avec des petites fonction que j'ai crée.
Donc cette notion me parait un peu floue (d'ou ma présence sur le chan débutant )

[Médinoc]

Exemple:

Code C :

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

1
2
3
4
5
6
int main(void)
{
	char unBufferSurLaPile[10];
	gets(unBufferSurLaPile);
	return 0;
}

Ce code fait un débordement de buffer sur la pile dès qu'on tape plus de 9 caractères. C'est justement pourquoi la fonction gets() est un bug et ne doit pas être utilisée...

[Hanz Peter Mariol]

Ok, ba non alors je ne pratique pas ce genre de chose.
Non mais en plus, j'ai bien étudier les fichiers, et ils ont parfaitement la meme forme et suive la meme procédure de traitement, et je ne travaille qu'avec des pointeurs dont la taille n'est définit qu'au cours du programme pour s'adapter au nombre de charactère de ma chaîne.
La bizarrerie vient vraiment du fait que certains fonctionnenent parfaitement et d'autres non, lancant une exception au moment de clore le programme lorsqu'ils ont fini toutes leur instructions.

Je ne peux linker le code, car il est bien trop gros et confidentiel, hélas. Sinon j'aurais vraiment aimé avoir un avis.
Mais comme je le disais dans mon message peu compréhensible, j'ai trouvé une solution pour palier le problème : Faire une première ligne assez lourde d'initialisation des automates, les multiples tests effectués furent concluant dans des tas de cas différents.

Je suis juste très déçu d'avoir une solution empirique et de ne pas etre sur de la théorie

[Médinoc]

Je vois bien un moyen gore (mais que je pense assez sûr) de quitter sans provoquer de crash, c'est d'appeler exit() (voire _exit() ou ExitProcess()) au lieu de retourner 0. Le problème, c'est que ça ne supprimera pas le bug de ton programme, ça ne fera que le contourner. Le bug, lui, peut causer des corruptions de données etc. etc...

[3DArchi]

Trouver ce genre de problème est souvent très très compliqué car on ne sait pas où se fait le débordement.
1er étape: relecture de code et notamment de toutes les variables locales,
2ème étape: utilisation d'un outil du marché (Purify, BoundChecker, etc...). Faut avoir des sous...

[Nogane]

Avant de partir dans une relecture complète du code(pacque je suis fainéant), je commencerai par retirer les morceaux de mon code qui me paraissent douteux(voir même tout retirer s'il le faut), et à les remettre progressivement jusqu'à trouver le bout de code qui provoque cette erreur.

C'est une méthode vielle comme le monde(du développement) mais qui marche toujours dans le cas d'erreurs a retardement.

[Hanz Peter Mariol]

Ouai j'aurais du faire ca mais je n'ai plus le temps.
Globalement, n'utilisant que des char* et des string, pour mes variables locales, je n'utilise pas à proprement parler de buffer que je peux overflow.

Dites vous que mon programme exploite un csv, qu'il traite ligne par ligne.

Tous ces csv ont exactement la même forme(puisque généré par un même programme très simpliste) et sont traités exactement de la meme manière, chaque ligne représentant finalement des variables et leurs valeurs associées.

Pourtant certains fonctionnent à merveille, et d'autres, juste avant le "return 0", retourne une exception, comme si l'adresse de retour avait été overloadée.
Mais le fait est que je n'utilise aucun buffer ou autres fonctions non protégée.

Ensuite je me suis aperçu que l'exception n'apparaissait pas si ma première ligne à traitée est une ligne assez longue, comportant grand nombre de variables. Le traitement de chaque ligne entraine la création de variables locales dynamiques (string, char***, ou objet propre à mon appli) que je desalloue après chaque ligne pour les recréer à la nouvelle.

Voilà vous savez à peu pres tout. Je vais me contenter de ma solution pour palier le problème, car je n'ai pas le temps de reprendre tout le code. Mais j'aimerais comprendre la théorie, comment est ce que cela fontionne avec un init? Et pourquoi certains csv qui n'ont vraiment rien de très particuliers entraine ce bogue? Surtout que je n'utilise point de buffer.

Bref, merci pour vos tentatives d'apport de connaissances à mon encéphale.

[3DArchi]

Et pourquoi certains csv qui n'ont vraiment rien de très particuliers entraine ce bogue?

Ton bug peut apparaître dans des cas particuliers mais simple que tu ne soupçonne pas. Ou, tout aussi probable, peut être systématiquement présent, mais ne pas avoir de conséquence visible dans la plus part des cas. En fait, tant que tu n'as pas clairement identifié le pb, tu ne peux savoir ce qu'il y a de particulier dans ton fichier, à moins que ce ne soit une variable non initialisée ou autre chose propre au programme, indépendant du fichier, d'où le caractère un peu aléatoire.

[Médinoc]

Comme tu programmes en C++, le plantage peut aussi avoir été déclenché par le destructeur d'une variable locale à main() ou globale...