Pourquoi une application agit-elle différemment après la connexion du débogueur VS?

Question

Il existe une application de bureau écrite en c # qui tente de gérer une connexion socket et échoue mais réussit une fois que la même application est attachée à Visual Studio.

comment peut-il être débogué?

Answer 1

Ceci est un exemple classique de timing.

Si cela fonctionne dans le débogueur, cela signifie que vous devez reformater un peu votre code pour gérer cela.

Maintenant, si vous êtes une application qui est un socket serveur qui reçoit des connexions de client et tente de générer un thread pour chacune de ces connexions, vous devrez peut-être envisager d'utiliser select () pour gérer les connexions dans un thread.

Answer 2

Je dirais que les problèmes de synchronisation liés au fait que le débogueur est connecté ralentiront légèrement le code, ce qui pourrait signifier qu'une condition de concurrence critique ne se produit pas.

Pour le déboguer et essayer d'ajouter du code de journalisation à votre application, j'utilise personnellement log4net

Vous ne devriez pas avoir de problèmes avec malloc ou autre, car vous codez en c #.

Si vous exécutez une application Web, il se peut également que le serveur Web Cassini diffère de celui que vous déployez.

Answer 3

Habituellement, les problèmes de synchronisation. Y a-t-il des discussions en cause? Si C / C ++, il pourrait y avoir beaucoup de raisons en raison de la façon dont les bogues de gestion de la mémoire pourraient se comporter.

Answer 4

Vous pouvez avoir des variables dont les valeurs par défaut sont différentes lorsqu’elles sont exécutées sous le compilateur et non autonomes. Les conditions de course pourraient être une autre idée si des fils sont impliqués.

Si vous allouez de la RAM via malloc ou une nouvelle, assurez-vous que la mémoire est correctement initialisée avant de l'utiliser.

Answer 5

Nous avons en fait rencontré un problème similaire. Le timing est un élément critique de cela. Ainsi que jeter des no-ops dans le code (différence primaire w / code débogué).

Avec la programmation de socket, il semble que le débogage avec VisualStudio.Net revient à avoir des appels supplémentaires Application.DoEvents (). Nous avons constaté que certains éléments ne fonctionneraient pas (sans débogage), sauf si nous permettons au composant de respirer (par exemple, gérer ses propres événements) en appelant Application.DoEvents ().

Answer 6

Lorsque Visual Studio se connecte à votre application, le CLR et le JIT ont des différences d'exécution subtiles pour permettre le débogage. Le ramassage des ordures, par exemple, est différent.

http://stupiddumbguy.blogspot.com /2008/05/net-garbage-collection-behavior-for.html

Answer 7

C’est peut-être parce que vous regardez des propriétés avec des effets secondaires dans votre débogueur. Bien que les autres réponses ici soient plus probables ...