Discussion :

[ceugniet]

Bonjour à tous

J'utilise Visual C++
(Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5 SP1

Édition installée*: VC Express

Microsoft Visual C++ 2008 91909-152-0000052-60848
Microsoft Visual C++ 2008)

Quelqu'un pourrait-il m'expliquer ce message d'erreur ?

A l'exécution d'un programme console, j'ai le message :

"Run-Time Check failure #2 - Stack around the variable 'line' was corrupted"

line est une variable de type char (char line[200]) qui fonctionne normalement pendant tout le programme. Elle est définie dans le programme main, et l'erreur survient au moment du "return" dernière ligne du programme main, après que j'ai fini d'utiliser cette variable line. En d'autres termes, tout marche bien jusqu'à la fin, mais j'ai cette interruption avec message d'erreur, alors que tout est fini.

Est-ce que quelqu'un a une idée ?

Merci d'avance de votre aide.

[therwald]

Euh, sans code c'est un peu dur...au hasard je dirais que tu écris en dehors de du tableau...genre c'est un tableau de longueur 200, tu y écris à l'index 200, qui est en dehors (index basé sur 0)

[ceugniet]

therwald, merci de ta réponse. En fait, je ne crois pas que cela soit la raison. D'abord parce que si je dépasse un tableau, il me semble que seuls le compilateur, lorsqu'il a l'information nécessaire, et le debugger, peuvent me le faire remarquer. Corrige-moi si je fais erreur, mais n'est-il pas parfaitement légal de faire référence à, ou même de définir, un élément d'un tableau en dehors de ce tableau ? Le debugger le voit - c'est l'une de ses fonctions - parce qu'il insère des tests de dépassement, mais à l'exécution sans debugger, ça passe sans problème.
La deuxième raison est que précisément j'ai déjà fait tourner le debugger et qu'il ne me signale pas de dépassement de tableau.
La troisième raison est que le debugger ne me dit absolument rien au moment précis où j'utilise pour la dernière fois line. Le programme plante au moment du return. J'ai essayé d'exporter dans une routine la création locale et l'utilisation de line. Le problème reste entier : c'est sur l'instruction return (de la routine) que survient le plantage, au moment où je n'utilise plus line, comme si c'était au moment où le système voulait supprimer line du stack (car line est un tableau local à la fonction) qu'il prenait conscience d'un problème.

Je comprends bien que sans le code, c'est bien difficile de me répondre. Je suis en train d'essayer de réduire le code à sa plus simple expression pour localiser mieux le problème et éventuellement de le mettre dans un prochain message.

Merci en tous cas de ta réponse rapide.

[ceugniet]

Au temps pour moi !

Merci de ne pas tenir compte de ma question. J'ai trouvé mon erreur. Et je n'en suis pas fier. Désolé de t'avoir mis à contribution pour une stupidité de ma part.

[pyros]

Salut,

Juste pour info, le compilateur ne peut être capable de détecter un "index out of bound", car les indexes sont rarement connue à la compilation:
Tu peux très bien allouer un char tableau[10] et demander à l'utilisateur quelle case il veut utiliser.

Ensuite, les débuggeurs "classiques" ne peuvent pas non plus détecter ce type d'erreur car les tableaux statiques sont quelque chose de très bas niveau (il s'agit juste d'une allocation mémoire sur la pile) et ne font aucun check sur leurs capacité. De plus, il est possible de faire des choses très sales mais "valide" avec. Par exemple:

Code :

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

1
2
3
4
 
int a[10];
int b[10]
int c = a[15];

Ici, on pourrait croire que a[15] n'est pas valide, mais comme la pile est alloué de manière contigüe, a[15] correspond en fait à b[5]. Donc ce code "marche", si l'on sait ce que l'on fait.

Attention !!! je n'ai pas dit que ce code était juste. Ce code est faux et ne respecte aucune norme. Il s'agit juste d'un hack utilisant la manière dont est gérée la mémoire sur certains systèmes.

Des outils comme valgrind ou glowCode permettent en générale de trouver ce genre de problème, mais le plus simple est d'utiliser des conteneur plus haut niveau comme les std::vector qui eux check leurs capacité lors du débugage.

[ceugniet]

Merci beaucoup Pyros.

Je suis d'accord sur les capacités limitées des compilateurs en ce qui concerne les dépasssements de tableaux. En revanche j'ai quand même souvenir de cas où le debugger m'a aidé à en trouver.

D'un autre côté, pour aller dans ton sens, j'ai remarqué que lorsque je lançais une exécution en mode debug après avoir modifié le code, un avertissement me rappelait que le code avait été modifié, ce qui, a contrario, laisse entendre que si le code n'a pas été modifié, le système considère qu'il n'est pas nécessaire de recompiler même si on exécute en mode debug, et par conséquent que l'exécutable pour un debugging n'est pas différent d'un exécutable normal. Il est possible, et même probable, que cette vérification des dépassements de tableaux soit une option du compilateur, mais j'avais oublié ça !

En fait, mon erreur n'était pas un dépassement de tableau, mais une erreur stpide sur laquelle je ne m'appesantirai pas...

Merci en tous cas de ta réponse.

[therwald]

Juste pour compléter l'info, il existe des techniques (prototype: la valeur "canarie") permettant de détecter certaines corruptions de pile. Ces techniques fonctionnent au runtime avec certaines options de compilation, et le déclenchement d'une erreur au return me semble justement assez typique. Ces techniques permettent, entre autres, de se protéger contre des failles permettant d'injecter du code par un débordement de pile provoqué.

ex: -fstack-protector sur gcc http://gcc.gnu.org/onlinedocs/gcc-4....dprotector-875