Discussion :

[sapphire]

Chalut

j'ai une pitite question toute bête:

en cas de crash d'un soft apparait une pitite dlgbox system indiquant l'adresse hexa de l'instruction provoquant le crash, ainsi que, dans le cas d'un bufferoverflow par exemple, l'adresse memoire que le soft a tenté d'accéder.

Comment, a partir de l'adresse de l'instruction, retrouver l'instruction dans le code source ?

ex: crash
l'instruction 0xAABBCCDD a provoqué une erreur a l'adresse 0xEEEEEEEE
memory can't be read/written

J'aimerais savoir comment retrouver, dans le code source, l'instruction qui se trouve a l'adresse 0xAABBCCDD du binaire, pour ensuite tracer les appels a cette instruction via la call stack.

vi, j'ai honte de pas trouver ca, mais cet IDE je pige pas encore la logique..

Merci

[Aurelien.Regat-Barrel]

J'espère que c'est pas pour débuguer un soft qui plante chez un client, auquel cas tu découvres l'utilité de générer un fichier de logs.
Sinon, ben on se demande pourquoi tu n'utilises pas un débogueur.
Mais bon, pour ta question, il faut déssassembler le soft pour savoir l'instruction (assembleur) précise, mais alors tu ne sais pas dans quelle fonction ça se passe, et tu peux oublier le callstack.
Alors la méthode du guerrier désespéré, c'est de compiler le soft en faisant générer un .map. Ce dernier te donnera l'emplacement de chaque fonction dans ton exe. Tu peux alors en déduire dans laquelle a eu lieu l'erreur.

[sapphire]

J'espère que c'est pas pour débuguer un soft qui plante chez un client, auquel cas tu découvres l'utilité de générer un fichier de logs.

hihi non en fait, je debug une appli opensource (env 100,000 lc, pas assez de temps pour tout lire) à laquelle j'ai ajouté quelques éléments de code. Problème: l'ajout se fait dans une dll multithread qui utilise des sockets. Donc, non seulement c'est galère de placer les points d'arret a cause des timeout réseau, mais en plus je ne suis jamais trop sur du thread exécutant mon code.
Bref

Sinon, ben on se demande pourquoi tu n'utilises pas un débogueur.

En fait, c'est ce que j'essaie de faire avec celui inclus dans visual .net
Donc, j'attache mon process, je provoque le crash, puis j'obtient la boite de dialogue decrite dans le premier post. Le debug visual pointe alors sur l' ASSERT qui a provoqué l'arret de lexec dans le code de l'exécutable. Mais l'info dont j'ai besoin, c'est l'instruction qui a provoqué le bo dans la dll.. pas celle de l'assert de l'exé qui l'a intercepté.

Jsuis pas sur d'etre bien clair, inutile de préciser que je suis pas vraiment dev

Mais bon, pour ta question, il faut déssassembler le soft pour savoir l'instruction (assembleur) précise, mais alors tu ne sais pas dans quelle fonction ça se passe, et tu peux oublier le callstack.
Alors la méthode du guerrier désespéré, c'est de compiler le soft en faisant générer un .map. Ce dernier te donnera l'emplacement de chaque fonction dans ton exe. Tu peux alors en déduire dans laquelle a eu lieu l'erreur.

Comment générer le fichier .map ? Suffit de compiler la dll en mode debug ? ou ya des options à activer quèquepart dans l'IDE ? Ya un tuto debug avec visualc++ sur developpez.com ?

[Aurelien.Regat-Barrel]

C'est l'ASSERT qui génère l'erreur. Cherche pas plus loin. C'est lui l'instruction, un assert sert à ça.
Remonte la pile des appels dans le débogueur pour comprendre pourquoi ça a fini comme ça. A vu de nez, ça sent la corruption mémoire... c'est quoi comme assert ? Si c'est invalid block ou truc du genre, vérifie tes new/delete, que tu mélanges pas plusieurs CRT.
Pour le map, c'est dans les options du projet, éditeur de liens -> débogage -> génération d'un fichier de mappage.
Mais apprends à utiliser le débogueur tu seras 100x plus efficace.
Si ta dll est compilée en debug, tu dois pouvoir "stepper into" dedans, notamment lors de la remontée de la pile d'appels.

[mat.M]

hihi non Smile en fait, je debug une appli opensource (env 100,000 lc, pas assez de temps pour tout lire)

Pas le temps pour tout lire ??
Tu prends pas les gens pour des idiots ?
J'espère que tu n'est pas rémunéré pour cela
Tu traces dans un fichier log comme Aurélien suggère ?