2

C# で記述されたデスクトップ アプリケーションがあります。ソケット接続を管理しようとして失敗します。Visual Studio デバッガーにアタッチされている場合、同じアプリケーションは成功します。

どのようにデバッグできますか?

4

7 に答える 7

5

タイミングの問題もデバッガーを接続するとコードの速度がわずかに遅くなり、競合状態が発生していないことを意味すると思います。

デバッグするには、アプリケーションにログ コードを追加してみてください。私は個人的にlog4netを使用します。

C# でコーディングしているため、malloc などの問題は発生しないはずです。

Web アプリを実行している場合、VS の cassini Web サーバーとデプロイ先の Web サーバーに違いがある可能性もあります。

于 2008-09-23T12:10:03.333 に答える
1

通常、タイミングの問題。関連するスレッドはありますか? C/C++ の場合、メモリ管理のバグがどのように動作するかにより、多くの理由が考えられます。

于 2008-09-23T12:07:02.047 に答える
0

実際に同様の問題が発生しました。タイミングはこれの重要な部分です。コードにno-opsをスローするだけでなく（デバッグされたコードとの主な違い）。

ソケットプログラミングでは、VisualStudio.Netを使用したデバッグは、追加のApplication.DoEvents（）呼び出しを行うようなものです。Application.DoEvents（）を呼び出してコンポーネントの呼吸を許可しない限り（たとえば、独自のイベントを処理する）、失敗する（デバッグしない）ものがあることがわかりました。

于 2008-09-23T13:21:40.557 に答える
0

Visual Studioをアプリケーションに接続する場合、CLRとJITには、デバッグを可能にするための実行時の微妙な違いがあります。たとえば、ガベージコレクションは異なります。

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

于 2008-11-20T07:29:23.127 に答える
0

デバッガーで副作用のあるプロパティを監視していることが原因である可能性があります。ここでの他の答えはより可能性が高いですが...

于 2008-11-20T07:59:31.973 に答える
0

スタンドアロンではなくコンパイラで実行する場合、デフォルト値が異なる変数がある場合があります。スレッドが関係している場合、競合状態は別の考えかもしれません。

malloc または new を使用して RAM を割り当てる場合は、メモリを使用する前にメモリが適切に初期化されていることを確認してください。

于 2008-09-23T12:09:54.770 に答える
0

これはタイミングの典型的な例です。

デバッガーで機能する場合は、これを処理するためにコードを少しリファクタリングする必要があることを意味します。

アプリがクライアントから接続を受信し、それらの接続ごとにスレッドを生成しようとするサーバー ソケットである場合は、select() を使用して 1 つのスレッドで接続を管理することを検討する必要があります。

于 2008-09-23T12:15:34.227 に答える