operateur new : erreur d'execution.

Bonjours à tous

Je vous contact aujourd'hui car je n'ai pas trouvé de solution à un souci très étranges.

Citation:

---

Windows a déclenché un point d'arrêt dans Engine.exe

Cela peut être dû à une défaillance du tas et indique un bogue dans Engine.exe ou l'une des DLL chargées.

La fenêtre Sortie peut contenir des informations de diagnostic supplémentaires

---

Visual m'ouvre sur une page blanche disant que les sources son disponible là ou ce situe le breakpoint. Et pourtant ... je voudrais bien avoir les détails supplémentaires, mais j'ai pas la console à l'exécution de mon programme. J'ai donc activé des breakpoint pour trouvé ou est le souci, et le plus bizar est qu'il arrive sur cette ligne :

Code:

---

1 2	VBO_LOADING * pTask = new VBO_LOADING ;

---

VBO_LOADING est une class. Seulement, j'ai dans d'autre cpp des lignes équivalente avec la même class, mais elles fonctionnent. Pourquoi ce souci et comment le régler ?
Pour info, je compile sous visual C++ 2010.

En l'espérance de votre réponse, je vous remercie de votre lecture.

Hello,
J'ai déjà eu ce type de problème, gros crash sur un allocation mémoire (avec visual 2005). C'était du à une précédente corruption mémoire via un buffer overrun dans une des dll utilisées. Vérifie si par hasard tu n'écrit pas en dehors des bornes d'un tableau quelque part avant ton new, ca peut venir de là...

Incroyable ! t'a pas tord sur ce coup là !!! effectivement j'écrivais en dehors d'un tableau, 162 ligne tandis que le tableau faisait 81 lignes ... Je suis étonné qu'il n'est pas bronché de ce bug. Un simple oublie d'un x2. J'ais longtemps été habitué à l'univers mac ou on me stoppait mon apply des que je dépassais les bornes du tableau. Alors je n'y avais pas du tout pensé. Merci beaucoup de ton aide ! :ccool:

J'ai souvenir que sous linux avec gcc, le dépassement d'écriture provoquait direct une belle segfault, donc ce comportement foireux est peut être propre à visual. De manière générale, remplacer tous les tableau par des vecteurs supprime le problème puisque l'opérateur [] vérifie la validité de l'indice passé en paramètre (ou alors c'est la fonction at(), je sais plus :aie:).

Citation:

---

Envoyé par vikki

J'ai souvenir que sous linux avec gcc, le dépassement d'écriture provoquait direct une belle segfault

---

Pas systématiquement non, ça dépends d'où tu écris en dépassant.

Oui, je compilais aussi sous gcc à l'époque et me sortait un exc bad access dès qu'il y avait un dépassement mémoire. Mais depuis, sous visual c++ je fais aussi de l'assembleur pour accéléré certaine taches, donc les erreurs sont facile à commettre (la preuve ^^).