Difference entre un GO (CTRL+F5) et une session de debugging (F5)
3 réponses
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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
marc
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 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
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
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" wrote in message 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
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" <marc.tessis@caramail.com> wrote in message
news:ed8791c5-e871-45bb-a004-a722029a0a1c@c29g2000yqd.googlegroups.com...
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
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" wrote in message 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
"Vincent Burel" a écrit dans le message de 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à)
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> a écrit dans le message de
news: 4a96b800$0$12658$ba4acef3@news.orange.fr...
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à)
"Vincent Burel" a écrit dans le message de 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à)
