Going off-off topic for this blog, but hey - I'm a software developer, this is what I do day to day.
I've recently came across the most puzzling bug. While porting some application from WinForms to a combination of WinForms/WPF environment, I traced a situation where a call to paint was supposed to be blocked on a lock, but instead a different control's paint entered and altered a shared class's internals. The result was the wrong presentation on the original paint. It was very hard to trace this bug.
I found the following related resources:
MSDN discussion thread: Paint reentrancy during thread sleep
Explained in this article:
WPF Fundamentals: Threading Model (look for "reentrancy and locking" segment)
For me - the bug isn't resolved yet. I'm still looking into ways to prevent the trace. The lock in paint here is unavoidable as it waits on access to video frame grabbers.
Update: - this is how I solved it, I added a push pop mechanism to the data that was changed internally inside the paint functions. Since the error was caused by lock not preventing paint reentry - the sequence was within one thread and sequential. Therefor the push/pop mechanism is assumed to have solved it.
I know no one cares, well - I hope you enjoy my other content. It's my blog, this is what I'm doing/thinking.