When Can Breakpoints Alter How Your Code Executes?

Question

I've run into a very odd bug today. I have a button on a form, clicking it causes a grid on my form to be populated with data. If you click the button twice, it crashes with an 'Object reference not set to an instance of an object.'

I ended up placing a breakpoint at the start of the Sub that handles the population of that grid and I found that...it didn't crash anymore. I'd click the button, press 'F5' in Visual Studio and it wouldn't crash. I did this, at least, 10 times, it was fixed.

Then, I removed the breakpoint, F5'ed, clicked the button and it crashes. Adding the breakpoint back in, allows it to work.

Can someone explain what is going on here? The grid I'm using is a 3rd party control (Infragistics) and the application is a WinForms app. I'm not doing any threading - my only thought is that it's some sort of 'race condition'? But even that doesn't really make sense to me.

EDIT: This is a VB.Net application / Visual Studio 2008

Answer 1

There may be some asynchronous loading of data going on here. Adding the breakpoint gives the asynchronous portion time to finish. When you click it too fast, it's still waiting for the data to finish loading or something, therefore the error. You may not have implemented this, but the 3rd party control may have.

Answer 2

It sounds like a timing issue & there must be some threading going on in the background - perhaps in the 3rd party control.

Can you get a call stack from the exception?

In release mode (or when there's no break point) you can click the button a second time before the first click has been fully processed.

When you've set the break point the debugger gets focus and allows the app to synchronise again.

You could disable the button as soon as it's been clicked and then re-enable it after processing has finished. That would stop the problem occurring if you can't fix the underlying problem (e.g. it's in the 3rd party control).

Answer 3

I would guess it has something to do with the time it takes to manually do the debug. Perhaps you have something heavy working (perhaps the connection to the database) that when you are debugging it has time to finish but when not debugging it crashes the application

Answer 4

One other possibility ...

Often, breakpoints can change the runtime behavior of a process, IF you're looking at the code at the breakpoint. For example, if you hover over a property, or have the locals window open, properties will be evaluated on the fly before proceeding into further code.

Since a Property's getter is, realistically, just a method, a poorly written class can actually do "extra" work in the property that is keeping your code from crashing.

This isn't particularly likely, but I did see this in one third party library that did lazy initialization of a property, but didn't initialize it correctly before one of it's methods. If you never looked at the property in code, it would throw an exception - but just accessing the property cleaned it up.