Difference entre un GO (CTRL+F5) et une session de debugging (F5)

Le
Vincent Burel
Hello,

j'ai une question bizarre tant mon problème est étrange :
Sous VC6

J'ai un programme qui voit une partie de son comportement changer (une
réception de données venant d'un driver) quand le soft est lancé
normallement (CTRL+F5 donc sans le debugger).

Que ce soit en mode Debug ou Release. Le comportement est le même, par le
debugger (F5) tout marche comme il faut. Alors que par l'exécution normale
un problème apparait sur une partie du soft. Notez que j'ai aussi tracé en
mode Release et que le comportement est le même (puisque j'éxécute toujours
sous le debugger), c'est à dire que ca marche parfaitement.

Alors ma question est : comment le debugger lance une appli (par rapport à
une éxécution normale) et qu'est ce qui pourrait faire la difference ?
Security ? access right ? library ?

Si qqn a une idée, ca m'intéresse
merci d'avance ?
VB
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
marc
Le #20000561
Vincent Burel a écrit :
Hello,

Alors ma question est : comment le debugger lance une appli (par rapport à
une exécution normale) et qu'est ce qui pourrait faire la difference ?
Security ? access right ? library ?...



Il fait surtout des initialisations (pointeurs) et optimisations
(dernière réponse de http://www.techinterviews.com/microsoft-win32-inte rview-questions)
Par contre celui de VC6 est plus permissif que les suivants
En debuggant avec VS 2003 et supérieurs, on peut trouver des erreurs
de dépassement mémoire non détectées par VC6
Vincent Burel
Le #20001221
oui, je connais la différence entre un Debug Build et un Release Build, mais
le phénomène est le même qqsoit le type.
En outre j'ai isolé le problème dans un source de référence qui ne laisse
pas de place à une erreur triviale de variable non initialisée.
De plus je fais aussi le test entre un lancement direct (Release Built)
lancé du Windows Explorer (et ca ne marche pas) et le même lancé par le
Dependency Walker (Start Progfiling) et là ca marche. Il y a donc bien une
différence dans la façon de lancer l'exécutable qui fait apparaitre le
problème...

C'est quoi donc que ca pourrait - etre cette différence ?
VB


"marc" news:
Vincent Burel a écrit :
Hello,

Alors ma question est : comment le debugger lance une appli (par rapport à
une exécution normale) et qu'est ce qui pourrait faire la difference ?
Security ? access right ? library ?...



Il fait surtout des initialisations (pointeurs) et optimisations
(dernière réponse de
http://www.techinterviews.com/microsoft-win32-interview-questions)
Par contre celui de VC6 est plus permissif que les suivants
En debuggant avec VS 2003 et supérieurs, on peut trouver des erreurs
de dépassement mémoire non détectées par VC6
Alain
Le #20004061
"Vincent Burel" news: 4a96b800$0$12658$
oui, je connais la différence entre un Debug Build et un Release Build,
mais
le phénomène est le même qqsoit le type.
En outre j'ai isolé le problème dans un source de référence qui ne laisse
pas de place à une erreur triviale de variable non initialisée.
De plus je fais aussi le test entre un lancement direct (Release Built)
lancé du Windows Explorer (et ca ne marche pas) et le même lancé par le
Dependency Walker (Start Progfiling) et là ca marche. Il y a donc bien une
différence dans la façon de lancer l'exécutable qui fait apparaitre le
problème...
C'est quoi donc que ca pourrait - etre cette différence ?



Difficile à dire comme ça.
Peut-être que si tu compiles/debug avec Visual 2008, il détecterait des
erreurs que VC6 n'a pas vu...
(c'est souvent des mauvais alloc/dealloc ces trucs là)
Publicité
Poster une réponse
Anonyme