Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » FuncEval   (RSS)

Func-eval abort is evil

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
Posted by jmstall | 6 Comments
Filed under:

Resolving functions and func-eval syntax

I got a question about MDbg's func-eval syntax, which brings up a nice point about function resolution: Is it possible to evaluate a function by specifying an instance variable instead of the fully qualified name of the class? f ex.get_StackTrace ...

Debugger won't properly evaluate C#s base keyword

Public Service Announcement: You may have noticed that trying to evaluate members using C#'s 'base' keyword in the debugger still calls the derived members. (The 'base' keyword lets you access base class member implementations from within a derived class,
Posted by jmstall | 8 Comments

"Correct" may depend on your point of view

Correctness from the debugger's perspective is very different than correctness from the end-user's perspective. For example, the debugger exposes many invasive operations like SetIp. The debugger considers the operation successful if it sets the IP to

What does a debugger author need to do to support func-eval?

I've mentioned func-eval (aka property eval) is evil for end-users; but it's also evil if you want to write a debugger that uses func-eval. For example, let's say you're writing your own managed debugger and you have a watch window, and you want to eval

What to do with a feature that only works 90% of the time?

Imagine when you're designing a feature if there was an operation that was very useful 90% of the time; but the other 10% of the time it was provably and innately unsafe (either crashed, deadlocked, or gave back garbage). By "innately unsafe", I mean
Posted by jmstall | 1 Comments
Filed under: , ,

Evil trick to render UI when stopped at a breakpoint.

Here's an EVIL trick to render your UI in a winforms app when you're stopped at a breakpoint. When managed-debugging, when you hit a breakpoint, all the managed threads stop . With a winforms app, the UI thread is managed and so it stops too. However,
Posted by jmstall | 2 Comments

Blog Category for Func-eval

I created a blog category for Func-eval (aka Property Evaluation), and I updated some of my old posts to be in this category. And while I'm at it, some other func-eval blog entries: GreggM on Func-eval and Winforms SteveJS on Nested Break States (stopping
Posted by jmstall | 6 Comments
Filed under: ,

Rules of Funceval

Funceval (aka "Function Evaluation" or "Property Evaluation") is the ability to inject some arbitrary call while the debuggee is stopped somewhere. A debugger commonly uses funceval to run ToString() and property getters. I want to describe when it is
Posted by jmstall | 5 Comments
Filed under: ,

Using Funceval to Inject code into another app

It's possible for a managed debugger to attach to an app and inject arbitrary stub code into the app, without any prior cooperation from the app. The more technical description is that while the debuggee is stopped, the debugger can load an arbitrary
Posted by jmstall | 5 Comments
Filed under:

Func-eval is evil

Function evaluation (aka “Func-eval”, “property evaluation”, “prop eval”) is the ability for a debugger to have the debuggee call a random function when stopped at a breakpoint. For eg, this lets you call functions from VS’s immediate window. Func-eval
Posted by jmstall | 12 Comments
Filed under:
 
Page view tracker