Pb en release et pas en debug

Bonjour,

j'ai un problème auquel google et moi n'arrivons pas à apporter une solution.

Je travaille sur un très gros projet (3M lignes), qui dans un certain cas particulier plante en release et pas en debug.
En Release (sans debugger attaché CTRL-F5), j'ai droit à une unhandled win32 exception
En Release avec debugger (F5) j'ai une Unhandled exception at 0x1733dba8 in myapp.exe: 0xC0000096: Privileged instruction.

En allant voir l'assembleur dans visual, à la ligne 0x1733dba8, j'ai juste :

Code:

---

1733DBA8 out dx,al

---

Par contre en debug, je ne peux pas aller voir le code au moment où ça plante en release, parce que pour une raison indeterminée, visual studio me maintient que je n'ai plus de code à cet endroit, alors que les projets concernés sont générés avec informations de DEBUG.

Au début, je me suis dit que c'était un pointeur non initialisé. Le problème, c'est que je suis sous windows, et que je n'ai pas purify. Donc pour trouver ce vieux pointeur : tintin.

Si vous avez une idée quelconque pour m'aider, elle sera vraiment la bienvenue!

thermomille

Salut,

Et si tu demandes à Visual de s'arrêter en cas d'exception (menu Debug, entrée Exceptions... et tu coches tout sauf C++ exceptions) ?

MAT.

Salut,

Merci de la bonne idée ;)

Mais j'ai toujours une unhandled win32 exception en release sans debugger

et une :
First-chance exception at 0x118eeaf2 in myApp.exe: 0xC0000005: Access violation reading location 0xffffffff.

ça ressemble à une pile complètement foutue ça non?

Mais comment savoir qui a essayé de lire cette adresse?

Merci beaucoup

thermomille

Citation:

---

Envoyé par regis.portalez

Mais j'ai toujours une unhandled win32 exception en release sans debugger

---

Ok, mais avec débogueur ?

MAT.

Citation:

---

Envoyé par regis.portalez

Salut,

Merci de la bonne idée ;)

Mais j'ai toujours une unhandled win32 exception en release sans debugger

et une :
First-chance exception at 0x118eeaf2 in myApp.exe: 0xC0000005: Access violation reading location 0xffffffff.

ça ressemble à une pile complètement foutue ça non?

Mais comment savoir qui a essayé de lire cette adresse?

Merci beaucoup

thermomille

---

Tu peux essayer de mettre un breakpoint hardware sur la lecture à cette adresse. Je ne sais pas si ça va fonctionner, vu que l'adresse est invalide - mais sait-on jamais.

Tu trouveras des sources sur le net qui permettent de faire ça, même sans debugger attaché. Cf par exemple ceci.

Une revue de code ? (2M lignes, c'est long, mais je suppose que tu dois pouvoir restreindre un peu ce scope en réfléchissant à ce qui se passe un peu avant l'explosion)
Des traces pour mieux voir quand le problème arrive ?
Une version d'évaluation d'un produit genre Intel parallel studio, Purify,... ou autre, ce qui te permettra une fois le problème trouvé d'avoir un bon argument pour pousser tes patrons à l'acheter ?
Un lock mémoire, non pas seulement sur l'adresse en question, mais partout où tu peux, histoire de voir dès qu'il y a un truc louche (à enlever du code final) ?
Des poulets noirs à égorger un soir de pleine lune ?

Citation:

---

Envoyé par regis.portalez

Salut,

Merci de la bonne idée ;)

Mais j'ai toujours une unhandled win32 exception en release sans debugger

et une :
First-chance exception at 0x118eeaf2 in myApp.exe: 0xC0000005: Access violation reading location 0xffffffff. [edit] avec debugger

ça ressemble à une pile complètement foutue ça non?

Mais comment savoir qui a essayé de lire cette adresse?

Merci beaucoup

thermomille

---

oulala, j'ai un peu de mal avec l'utilisation du bouton éditer...

Les poulets noirs me paraissent une bonne idée, qui est surtout plus facile à réaliser qu'avoir une version de purify ou parallel studio :cry:

Qu'est ce qu'un breakpoint hardware?

Et pour quelles raisons (théoriquement) la pile peut être pourrie à ce point?
Je ne m'y connais malheureusement pas assez dans ce domaine pour savoir comment orienter mes recherches.
Comment visualiser la mémoire sans outil à la valgrind? Puis-je le faire à la main?

Enfin je suis un peu perdu...

Merci beaucoup à vous tous en tout cas :)


[EDIT] : j'ai réussi à avoir parallel studio en eval. Je dois avoir à peu près 200 erreurs mémoire. C'est parti pour la journée ;) Merci beaucoup à tous

+1 pour la code review. Generalement, c'est un comportement indefini (le plus courant d'apres mon experience est la variable non initialisee qui prend par hasard une valeur correcte en debug et pas en optimise). Je suis loin d'etre sur que de chercher a remonter les choses a partir du crash en optimise sert (la cause est avant le crash. et il peut y avoir loin du probleme a la consequence).

La dichotomie (la moitie en release, l'autre en debug. Puis on rafine) peux aider parfois a restreindre le scope. J'ai du aller une fois jusqu'a decouper une fonction... c'etait en fait un bug de l'optimiseur. C'est rare mais c'est possible (et la code review n'aide pas).

Ajouter des traces aide aussi parfois quand on a une meilleure idee de la cause.