Pbl d'exception

Salut à toutes et à tous !

J'ai un souci avec une exception.
J'ai récupéré la déclaration d'une classe basée sur l'ODE de numerical recipies (pour résoudre les équations différentielles sur la base de la méthode de Runge-Kutta), et j'ai donc essayé de m'en servir.

Cette classe comporte entre autre une fonction free_vector qui sert comme vous l'aurez compris à libérer la mémoire d'un vecteur (entendre par là un tableau quoi). Cette fonction n'est ni plus ni moins que l'appel de delete[].

Donc lorsque je débug mon programme, je me rends compte que l'appel à cette fonction ne pose aucun problème, jusqu'à ce que j'arrive à la ième itération, où là ben ça coince. Je comprends pas pourquoi. Le vecteur en question a été créé, il a une adresse, cette adresse est bien passée à la fonction free_vector, mais delete[] me retourne une exception comme quoi il trouve pas l'adresse (adresse violation).

Quelqu'un aurai-il une tite idée ? Merci

En général, ce genre de chose arrive quand il y a de la mémoire corrompue quelque part. Le plus grave, c'est que souvent, l'endroit où il y a l'erreur dans code et l'endroit où elle se manifeste n'ont rien à voir.

Il y a plusieurs méthodes pour corriger ça :

• Une revue de code (c'est encore l'une des plus efficaces...)
• Une réécriture du code avec des outils plus adaptés (certainement le mieux, puisqu'on a après un code meilleur, mais peut être assez long). Par exemple, vu le domaine d'application, utiliser une vraie classe de vecteur mathématique qui se charge seule de la gestion de la mémoire et qui (en mode débug tout du moins) vérifie qu'on ne dépasse pas les bornes d'n tableau a de fortes chances de localiser le problème
• Il y a des outils pour analyser la mémoire, comme purify ou boundscheckers
• J'ai vu une technique sympa dans un vieux CUJ,(avril 2002) : L'Os peut déclarer une zone mémoire en lecture seule. On déclare donc ce tableau ainsi sauf quand on y touche depuis un endroit autorisé, et l'OS se charge de trouver à quel moment un autre bout de code viens mettre son bordel
• Parfois, en regardant la mémoire brut, on arrive à identifier à quoi correspondent les zones à côté de celle qui est corrompue, et donc à cibler des suspect.

Bon courage !

Merci JolyLoic
Comme je suis pas un cador en programmation, et que je suis très loin de connaitre toutes les ficelles du C++, je suis pas sur de tout comprendre...
Mais bon c'est pas bien grave puisque ce que je retiens, c'est que c'est pas un problème bien simple à résoudre, et que la meilleure façon pour moi de le résoudre c'est de revoir totalement ou de récrire mon code.
Donc je vais m'atteler à la tâche, de longues heures en perspectives :D

Je n'ai jamais lu la version C++ des numerical recipes, mais si tu utilises la version C de celles ci, je pense que le plus efficace sera de remplacer tous ces tableaux par des équivalents qui peuvent vérifier les bornes et gérer l'allocation eux-même. Normalement, ça ne demande pas tant de boulot que ça, et seules la création et la destructions ont besoin d'être modifiés en général, pas l'utilisation.

Eventuellement, tu peux poster un bout de code, et je te montre comment le transformer.

--
Loïc

Hello,
Bon alors finalement, c'était bien une erreur dans mon programme. Je jongle en fait pas mal entre matlab et plusieurs versions de mes programmes, et du coup y'a des numérotations qui changent dans les tableaux....bref un bazarre à ma façon :-D
Mais comme je me le dis souvent, quand y'a un souci qui dur un peu trop, faut se reposer la tête une tite journée, et y revenir tranquille ensuite. En général le problème est résolu illico.
Pour ton info JolyLoic, je ne connais pas non plus la version C++ des numerical recipies (elle est payante :( ) mais par contre, pour ce que je voulais faire (utiliser la méthode Runge-Kutta pour résoudre des équations d'évolution non-linéaires couplées....), j'ai trouvé une belle adaptation C++ des fonctions offertes dans NR en C. Si tu veux le site où j'ai trouvé le code :
http://www.ujf-grenoble.fr/PHY/COURS...ungeKutta.html
Voilà, donc pour finir, tu avais raison, le mieux est de reprendre son code, et surtout l'endroit où l'erreur est indiquée par le debugger n'est pas forcément l'endroit où elle se produit réellement.
@+ et merci encore....