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).