Question

I have investigated this issue now since some time and it seem obvious to me that the placement of ordinary breakpoints influences the runtime behavior of the program dramatically.

I am speaking here of conditional breakpoint e.g. when setting the breakpoint condition to var == null then this case never occurs but when I remove the breakpoint the situation that var == null occurs often.

Could that be ?

Appendix:

Well my code is multi-threaded so it’s hard to post code in order to reproduce the error. Basically I have two threads. One is enqueuing items in a queue and the other is permanently dequeing items from the queue. In the code-snipped below I have the situation that the first thread never enqueues null items but for some reason they are finding their way into the queue. That let me insert the if-statement in order to prevent the NullReferenceException. Although being a temporary workaround my program did run from then on. Then I was interested in how often a null item gets dequeued from the queue and I placed a conditional breakpoint in the line with the if statement with the condition inv == null. The effect now is, when there is a breakpoint inv never seems to be null and when there is no breakpoint inv seems to be often 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();

                    }
                }
            }
        }

Again my problem began when some items in the queue began to be null items although I never add null items. Even for that reason I have placed a line that throws an Exception when there is something null. The Exception never gets thrown but I still have null items in my queue and I have no clue why.

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();
        }
    }

Answer 1

“conditional breakpoints” definitely affect timing. If you have a race condition it will definitely change behavior. You could also start seeing timeouts.

This is because there is no such thing as a true “conditional breakpoint” on most processors. What you actually have is “breakpoint, followed conditionally by automatically resuming execution”, and that is pretty slow even when the condition isn’t satisfied, because the debugger breakpoint handler has to run, read memory, test the condition, and then issue a continue.

---

Now that you’ve posted your code, I think I see the problem.

You’re not checking the return value of TryDequeue. When there’s nothing to dequeue, inv will be null, not because null was put into the queue, but because no items are in the queue at all.