Managed Debugging doesn’t support Fibers

Although managed-debugging definitely supports multi-threaded debuggees, it does not support debugging processes with fibers.

The V2.0 CLR provides fiber support, however the ability to debug fiber-mode applications was cut.

There are a few reasons that you don’t get fiber-mode debugging for free:

1) Fibers confuse certain CLR operations like the cooperative synchronization. (See steps 14 + 15 here). This may cause deadlocks.

2) Fibers will confuse traditional thread-based locks and thus cause deadlocks from fibers holder key locks getting switched out.

3) The runtime heavily uses thread-local-storage, which needs to be changed to fiber-local-storage to work with fibers. There are similar issues for anything using thread identity (such as GetThreadId).

4) The debugging API needs to be updated to be aware of fibers. Looking at ICorDebug, you can observe the following things:

a. there’s an ICorDebugThread, but no ICorDebugFiber.

b. ICorDebugThread returns an OS Thread ID, which prevents shoehorning a fiber into a thread at the API level.

c. There’s no concept of thread – fiber mappings. For example, if thread X schedules fibers A,B, and C, the debugging API may naively only see thread X.

5) Unlike threads, Fibers can be switched out, which would heavily impact the implementation of many operations such as stepping and inspection. For example, what should SetContext() on a switched out fiber do: fail or delay set the context once the fiber is restored?

6) Interop-debugging (mixed-mode) does extremely evil things requiring very intimate knowledge of a thread (such as hijacking the context), and completely falls apart with fibers.

This is unfortunate because it means that apps can use fibers and run great outside of a debugger but then will die under a debugger, which completely violates the principle that debuggers should not change behavior.

Ultimately we cut debugger fiber mode because we believed it wasn’t a core enough scenario and we could redirect our resources into more valuable areas (such as things listed here). Part of our motivation was that we believed clients would only use fibers as an optimization to a scheduler, and that any fiber-based app could be run in a non-fiber mode and thus debugged.  We didn’t anticipate clients using fibers to do things like implement coroutines (although this could always be switched to a thread-mode for debugability).

Unfortunately, the error handling here has traditionally been poor. Starting in VS 2005 Beta 2, we’ll finally detect and warn the debugger if fibers are being used.