1

私はこの問題をしばらく前から調査してきましたが、通常のブレークポイントの配置がプログラムの実行時の動作に劇的な影響を与えることは明らかです。

ここでは、条件付きブレークポイントについて話します。たとえば、ブレークポイント条件を設定するとvar == null、このケースは発生しませんが、ブレークポイントを削除すると、var == null頻繁に発生する状況になります。

それでいいの？

付録：

私のコードはマルチスレッドなので、エラーを再現するためにコードを投稿するのは難しいです。基本的に私は2つのスレッドを持っています。1つはキュー内のアイテムをキューに入れ、もう1つはキューからアイテムを永続的にデキューします。以下のコードスニップでは、最初のスレッドがnullアイテムをキューに入れることはありませんが、何らかの理由でキューに入る方法を見つけているという状況があります。これにより、 NullReferenceExceptionを防ぐためにifステートメントを挿入できます。一時的な回避策ですが、それ以降、私のプログラムは実行されました。次に、nullアイテムがキューからデキューされる頻度に関心があり、条件付きのifステートメントの行に条件付きブレークポイントを配置しました。inv == null。現在の効果は、ブレークポイントがある場合はinvがnullに見えず、ブレークポイントがない場合はinvがnullになることが多いということです。

public void _dequeue () {

            while (!Signals.TerminateSignal.WaitOne(0, false)) {

                if (Signals.DequeueSignal.WaitOne()) {

                    lock (Queue) {

                        IInvocation inv;
                        Queue.TryDequeue(out inv);

                        // Conditional Breakpoint
                        if (inv != null)
                            inv.Invoke();

                        _poolHooks[PoolIndex].DecrementWaiting();
                        _poolHooks[PoolIndex].IncrementPending();

                        if (Queue.Count == 0) Signals.DequeueSignal.Reset();

                    }
                }
            }
        }

再び私の問題は、キュー内のいくつかのアイテムがnullアイテムになり始めたときに始まりましたが、nullアイテムを追加することはありません。そのためでも、何かnullがある場合に例外をスローする行を配置しました。例外がスローされることはありませんが、キューにnullアイテムが残っているため、理由がわかりません。

public static void EnqueueInvocation (int poolIndex, IInvocation inv ) {

        if (inv == null) throw new Exception("Red Alert");

        lock (_deqThreads[poolIndex].Queue) {

            _poolHooks[poolIndex].IncrementWaiting();


            _deqThreads[poolIndex].Queue.Enqueue(inv);
            _deqThreads[poolIndex].Signals.DequeueSignal.Set();
        }
    }
4

3 に答える 3

10

「条件付きブレークポイント」は間違いなくタイミングに影響します。競合状態がある場合、それは間違いなく動作を変更します。タイムアウトが表示されるようになることもあります。

これは、ほとんどのプロセッサに真の「条件付きブレークポイント」などがないためです。実際に使用しているのは「ブレークポイント、条件付きで自動的に実行を再開する」です。これは、デバッガーブレークポイントハンドラーを実行し、メモリを読み取り、条件をテストしてから発行する必要があるため、条件が満たされていない場合でもかなり低速です。継続する。

コードを投稿したので、問題が発生したと思います。

の戻り値をチェックしていませんTryDequeue。デキューするものがない場合、キューに入れられたためではなく、キューにアイテムがまったくnullないため、invはになります。null

于 2012-07-10T17:25:36.727 に答える
1

これらのブレークポイントは、コードの実行にまったく影響を与えないようにする必要があります（タグ付けされたコード行の速度を落とす以外）。誤って書いvar = nullたり、似たようなものを書いたりしていませんか？タイミングに関連する問題でもある可能性があります（たとえば、コードが遅いため、マルチスレッドの状況/競合状態が発生することはめったにありません）が、最終的にはわかりにくいです-少なくとも、これらを使用しただけでは、一般的な問題や不利な点はありません。

于 2012-07-10T17:28:43.650 に答える
1

ブレークポイントをどこに設定しても、xの評価で動作に違いは見られません。

    static void Main(string[] args)
    {
        var x = new object();
        if (x == null)
        { Console.WriteLine("x is null"); }
        else
        { Console.WriteLine(x.ToString()); }
        x = null;
        if (x == null)
        { Console.WriteLine("x is null"); }
        else
        { Console.WriteLine(x.ToString()); }
    }

System.Objectx
がnull

于 2012-07-10T17:37:23.053 に答える