Func-eval is evil. Func-eval abort is even worse. For those coming in late, Func-eval is when the debugger hijacks a thread and has it evaluate some function such as a property-getter or to-string. Func-eval abort is when that evaluation hangs, and then the debugger aborts it (similar to Thread.Abort).
Visual Studio sets up a timer when it does automatic func-evals, and will automatically issue an abort after a few seconds.
For example, say you have a very very evil property like the one below.
public string EvilProperty
Thread.Sleep(1000 * 10);
If you allocate an Evil object in VS, and then view it in the watch window, VS will automatically func-eval the property getters (if func-eval is enabled). If the eval takes too long (which that Sleep will ensure in this case), it will abort the func-eval. It looks like this:
(screenshots courtesy of Windows Live Writer! )
ICorDebug?For debugger authors implementing func-eval support, the corresponding APIs are ICorDebugEval::Abort and ICorDebugEval2::RudeAbort. Like most ICorDebug operations, these are asynchronous. Issue them, call Continue(), and then wait for an Abort Complete (EvalComplete/EvalException) event.
So why is it evil?
Some reasons why abort is evil and should not be a backbone of any debugging strategy: