Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
exception de type EAccessViolation
dans un prog sous Builder c++ où le prog principal(thread) crée 2 autres threads secondaires, j'ai un bug de type :
raise exception classe EAccesViolation with message "Access Violation at address 00BC2E67. Write of address 0000D638"
quelqu'un a une idée?
merci
Salut,
n'aurais tu pas quelques lignes de codes à nous fournir ?
A quel moment se produit ton erreur ? Lors de la compilation ? Lors de l'exécution ? As tu tenté un debug pas à pas pour localiser précisément la ligne de code incriminée?
Sinon, le type de message peut indiquer qu'il manque un new quelque part entre une déclaration et l'utilisation d'un objet.
j'ai fait du pas à pas....mais Builder C++ ne permet pas d'accéder aux adresses que j'avais indiquées, de manière à savoir qui écrit quoi, et qui fait appel à cette adresse...........
Par contre, j'ai:
void __fastcall TSerial::SetTypeEvenement(TSerial::TypeEvent value)
{
FTypeEvenement = value;
}
et d'un autre coté j'ai:
enum TypeEvent {thread=0,synchro};
en quelque sorte, FTypeEvenement est initialisé à 0 (soit à thread, dans le constructeur) et lorsque j'exécute en pas à pas, je vois qu'il prend la valeur 1 (synchro) dans le test (FTypeEvenement==teThread)...Quand je force la valeur à "0", en pas à pas (Ctrl + F7), le bug disparait.................
A aucun moment dans l'immense code, il n'est dit que FTypeEvenement prend la valeur "synchro" (1)....Tout ce passe comme si une tierce a changé cette valeur..........
Tu n'as pas un FTypeEvenement++ ou Succ ?
tu n'as pas un if (FTypeEvenement = synchro), une affectation = au lieu d'une condittion ==
tu as pensé à mettre un except dans la clause else de FTypeEvenement == teThread , mettre des OutputDebugString pour logguer chaque etape et descendre au fur et à mesure?
Car si il y a un bug si FTypeEvenement == synchro, c'est déjà dans les codes lancés dans ce contexte qu'il faut chercher !
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
il y a bien un if/else dans la condition.....
par contre, je ne comprends pas ce que tu veux dire par utilisation OutputDebugString (peux-tu détailler?)
il y a un bug car FTypeEvenement prend une valeur qu'il est censé ne pas prendre..Je vais jetter un coup d'oeil dans la condition if(FTypeEvenement== synchro) car elle pourrait influer sur if(FTypeEvenement==thread)............
OutputDebugString te permet d'afficher une chaine dans le debugger. Ca te permet de tracer l'exécution pour voir où tu passe. Ca peut aider à y voir plus clair, surtout pour debugger du MultiThread. Bien entendu, faut compiler en mode Debug.Envoyé par titajeff
En appuyant sur la touche F1, tu aurais pu avoir ces informations par toi-même
En multiThread, les erreurs les plus courantes sont :
- De modifier une même variable depuis 2 thread différent (ou de la lire depuis un thread pendant qu'un autre la modifie) sans synchroniser. Dans ce cas, un objet de synchro type MultiReadExclusiveWrite fait très bien l'affaire.
- Manipuler l'interface graphique depuis un thread secondaire sans le faire dans un Synchronize.
Répondre avec citation
Partager