Discussion :

[Fabllot]

Bonjour,

Voilà un petit problème qui commence à me peser : J'ai un projet assez gros en C avec une API win32 et quelques interfaces C++, le tout compilé sous Visual Studio 2005 Pro. Quand je compile et débuggue avec visual : pas de soucis (aussi bien en mode "Debug" qu'en "Release"). Cependant, quand je lance directement l'exécutable, j'ai énormément de bugs qui apparaissent... Windows XP Pro me propose alors de lancer Visual pour tenter de débugger, mais il n'arrive pas à localiser les erreurs...

Je compile en mode "Multithread" (/MT), et a priori, le problème ne vient pas de là...

L'erreur que me renvoie Windows est :
L'instruction à "0x..." emploie l'adresse mémoire "0x...". La mémoire ne peut être "read".

Si jamais vous aviez une idée...

[farscape]

salut,
oui on a une petite idée tu as un bug...
le fait que ça fonctionne en debug n'est pas une garantie absolu.
ça ne te preserve pas des débordements mémoire, ou de variable pointeur non initialisée correctement à null dans le constructeur d'un objet par exemple...

[Fabllot]

le fait que ça fonctionne en debug n'est pas une garantie absolu.

Bah, le problème c'est que ça marche aussi en "release" quand on lance l'appli à partir de visual... Si on lance directement l'exécutable, sans passer par Visual, c'est là que ça se gâte...

[farscape]

hé bien tu as un bug de contexte ,ça devrait te renseigner sur sa nature.
tu n'as pas mis le message exact de ton erreur , ça ressemble a un acces illicite d'une zone memoire par exemple 0x0 .
ça peut venir de l'utilisation ou non des arguments du programme..

procéde par dichotomie en mettant des message box pour approcher au plus prés de l'erreur en release..

[Fabllot]

Le message d'erreur exact est :
L'instruction à "0x784ab21d" emploie l'adresse mémoire "0x00f677c5". La mémoire ne peut être "read".

et parfois il y a l'erreur suivante :
L'instruction à "0x..." emploie l'adresse mémoire "0x00000000". La mémoire ne peut être "written".

[farscape]

ben oui ça sent la non initialisation ou le débordement mémoire a plein nez.
suit mon conseil:

procéde par dichotomie en mettant des message box pour approcher au plus prés de l'erreur en release..

Ps: tu es bien sur que tous tes modules (.lib+exe) utilisent l'option /MT ?
pas de probléme avec le chargement d'une mauvaise dll (en debug par exemple)?.

[Fabllot]

tu es bien sur que tous tes modules (.lib+exe) utilisent l'option /MT ?
pas de probléme avec le chargement d'une mauvaise dll (en debug par exemple)?.

A priori, pas de problème de ce coté...

procéde par dichotomie en mettant des message box pour approcher au plus prés de l'erreur en release..

Je vais m'atteler à la tâche...

[Fabllot]

Après huit jours de débuggage et de recherches (non intensives!!!), j'ai finalement trouvé le problème... C'était juste un accès illégal à la mémoire, qui provoquait une erreur, non pas sur le moment, mais un peu plus tard lors d'un appel à un "malloc"...

Désolé de vous avoir dérangé pour une bétise!

[farscape]

hé oui comme prévu ...