FuncEvil, the Clipboard, and Deadlocks
Mike Stall has a great post that, for a debugger dev, is the moral equivalent of sticking a fork in a toaster. The basic problem he addresses is that once you are stopped in the debugger the UI for your application will no longer paint. What if you need to see something on that UI? If you like to live on the edge, Mike’s Evil trick to render UI when stopped at a breakpoint is the answer for you. Unfortunately, you need to be stopped on the UI thread for it to work. Pumping messages on another thread will not unblock the UI to paint. Even more unfortunate is that switching threads in the debugger won’t help. Function evaluation when debugging managed code requires you to be at a reasonable point on the thread. It is very unlikely you will randomly be at such a point, unless you stopped on the thread in question. You can see the result I got when I stop on another thread, then switched to the UI thread:
?System.Windows.Forms.MessageBox.Show("pump")
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.”
Now don’t let this dissuade you from how useful this very, very, very dangerous trick can be. Sometimes playing with fire is useful.
Not rendering the UI is only one problem that can happen due to the debugger stopping a process. A really bad problem that lack of message pumping can cause is clipboard deadlock. The real problem is due to delayed rendering, which requires the app that copied to the clipboard to be live. You can read about delayed rendering on the MSDN Clipboard Operations page. The basic problem is that the application you are debugging owns the clipboard, and other apps need it to respond to messages to get the contents of the clipboard. You can see this by creating a trivial winform app with a button and a RichTextbox:
(Note you need to use a RichTextBox here … a normal TextBox will actually copy the contents to the clipboard rather than using delayed rendering.)
First set a breakpoint in the button handler. Then select the “Copy me at your own Risk!” text and copy it to the clipboard with Ctrl-C. Now hit the button. Nothing is wrong yet. However if you go to any application and hit paste that application is now hung, and will remain so until you continue from the breakpoint. If you hit paste in the debugger you’ll deadlock that too without any way to continue from the bp. Clipboard deadlock has hit me few a times composing mail while stopped at a breakpoint. Using the trick that Mike outlines does free the applications waiting for your winform app to provide the clipboard data.
If you do not understand why func eval is evil I must end by pointing you to Mike's older post Func-eval is evil, and GreggM's more recent post Func eval and System.Windows.Forms.Form. Func Eval is powerful, and with great power comes a bunch of power to shoot yourself in the foot. Be careful using func eval.
