0

したがって、リモートコンピューターからのコマンド確認応答を処理するこのコードがあります。場合によっては(14日に1回程度)、次の行でnull参照例外がスローされます。

computer.ProcessCommandAcknowledgment( commandType );

私を本当に悩ませているのは、その前にnull参照をチェックしているので、何が起こっているかわかりません。その価値の完全な方法は次のとおりです。

    public static void __CommandAck( PacketReader reader, SocketContext context )
    {
        string commandAck = reader.ReadString();

        Type commandType = Type.GetType( commandAck );

        Computer computer = context.Client as Computer;

        if (computer == null)
        {
            Console.WriteLine("Client already disposed. Couldn't complete operation");
        }
        else
        {
            computer.ProcessCommandAcknowledgment( commandType );
        }
    }

手がかりはありますか?

編集:ProcessCommandAcknowledgement:

    public void ProcessCommandAcknowledgment( Type ackType )
    {
        if( m_CurrentCommand.GetType() == ackType )
        {
            m_CurrentCommand.Finish();
        }
    }
4

8 に答える 8

4

あなたが提供した情報に基づくと、その場所でnullrefが発生することは確かに不可能のようです。したがって、次の質問は、「特定の行がNullReferenceExceptionを作成していることをどのようにして知ることができますか?」です。デバッガーまたはスタックトレース情報を使用していますか?コードの製品版またはデバッグ版を確認していますか?

デバッガーの場合、基本的にデバッガーが別の場所でNullRefを報告しているように見えるさまざまな設定の組み合わせ。その主なものは、JustMyCode設定です。

私の経験では、例外が実際に発生する行を判別するための最も信頼できる方法は...

  1. JMCをオフにします
  2. デバッグでコンパイル
  3. Debugger-> Settings-> Break onThrowCLR例外。
  4. デバッガウィンドウでStackTraceプロパティを確認します
于 2008-12-26T23:58:49.600 に答える
2

ReadString()nullを返す可能性はありますか?これにより、GetTypeが失敗します。おそらく、空のパケットを受信しましたか?または、文字列がタイプと一致しない可能性があるため、後で使用するときにcommandTypeはnullになります。

編集m_CurrentCommand呼び出したときにnullではないことを確認しましたProcessCommandAcknowledgmentか?

于 2008-12-26T23:25:07.093 に答える
2

TCP フレーミング コードに問題があることは間違いありません (問題がある場合)。

「PacketReader」はおそらくそうしないことを示唆しています。技術的には、「FrameReader」または同様の名前が付けられるためです。

関連する 2 台の PC がローカル LAN などにある場合、おそらく 14 日間の間隔で説明がつくでしょう。インターネット経由でこれを試した場合、特に WAN 帯域幅が競合している場合は、エラーの頻度がより一般的になると思います。

于 2008-12-27T00:12:07.203 に答える
1

最適化を有効にしている場合、実際に最適化が行われる非常に間違った場所を指している可能性があります。

数年前、私にも似たようなことがありました。

于 2008-12-27T00:16:52.963 に答える
1

または、コンテキストが別のスレッドによって null に設定される場所でスレッド競合が発生する可能性があります。それはまた、エラーの珍しいことを説明するでしょう.

于 2008-12-27T00:18:55.643 に答える
1

わかりました、実際にはいくつかの可能性しかありません。

  1. どういうわけか、そのルーチンを呼び出すまでに、コンピューターの参照が踏みにじられています。

  2. 呼び出しの下の何かが null ポインターの逆参照エラーをスローしていますが、その行で検出されています。

それを見ると、スタックが破損していて、computer自動が壊れているのではないかと非常に疑わしい. 問題のあるサブルーチン/メソッド/関数呼び出しを確認してください。特に、「コンピュータ」アイテムに作成しようとしているものが実際に期待どおりのタイプであることを確認してください。

于 2008-12-27T00:25:05.787 に答える
1

他のスレッドは何をしていますか?

編集:サーバーはシングルスレッドであると述べていますが、別のコメントは、この部分がシングルスレッドであることを示唆しています。その場合でも、並行性の問題が発生する可能性があります。

ここでの結論は、マルチスレッドの問題または CLR バグのいずれかがあるということです。どちらがより可能性が高いと思うかを推測できます。

于 2008-12-27T00:37:31.300 に答える
1

computer.ProcessCommandAcknowledgement( commandType );

これにステップインできるデバッグ シンボルはありますか?

ProcessCommandAcknowledgement によって null ref 例外がスローされ、バブルアップする可能性があります。

于 2008-12-27T00:48:34.850 に答える