VS デバッガーがアタッチされた後、アプリケーションの動作が異なるのはなぜですか?
https://stackoverflow.com/questions/120556
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
C# で書かれたデスクトップ アプリケーションがソケット接続を管理しようとして失敗しましたが、同じアプリケーションを Visual Studio にアタッチすると成功しました。
どうやってデバッグできるのでしょうか？
解決
これはタイミングの典型的な例です。
デバッガで動作する場合は、これを処理するためにコードを少しリファクタリングする必要があることを意味します。
ここで、アプリがクライアントから接続を受け取るサーバーソケットであり、それらの接続ごとにスレッドを生成しようとしている場合は、select() を使用して 1 つのスレッドで接続を管理することを検討する必要があるかもしれません。
他のヒント
デバッガを接続するとタイミングの問題も発生し、コードの速度がわずかに低下するため、競合状態が発生していない可能性があります。
デバッグするには、アプリケーションにログ コードを追加してみてください。私は個人的に使用しています。 ログフォーネット
C# でコーディングしている場合、malloc などの問題は発生しないはずです。
Web アプリを実行している場合は、VS の cassini Web サーバーとデプロイ先の Web サーバーに違いがある可能性もあります。
通常、タイミングの問題です。関係するスレッドはありますか?C/C++ の場合、メモリ管理のバグの動作により、多くの理由が考えられます。
スタンドアロンではなくコンパイラで実行すると、デフォルト値が異なる変数が存在する可能性があります。スレッドが関係している場合、競合状態は別のアイデアになる可能性があります。
malloc または new 経由で RAM を割り当てる場合は、使用する前にメモリが適切に初期化されていることを確認してください。
実際に同様の問題に遭遇しました。これにはタイミングが重要です。コードに no-op をスローするだけでなく (デバッグされたコードとの主な違い)。
ソケット プログラミングでは、VisualStudio.Net を使用したデバッグは、追加の Application.DoEvents() 呼び出しが行われるようなものであるように思えます。コンポーネントが呼吸できるようにしないと (デバッグ以外で) 失敗するものがあることがわかりました (例:Application.DoEvents() を呼び出して独自のイベントを処理します。
Visual Studio がアプリケーションに接続されると、CLR と JIT にはデバッグを可能にするためのランタイムの微妙な違いがあります。たとえばガベージコレクションは異なります。
http://stupiddumbguy.blogspot.com/2008/05/net-garbage-collection-behavior-for.html
デバッガで副作用のあるプロパティを監視していることが原因である可能性があります。ここでの他の答えの方が可能性が高いですが...
