Partager via

Managed Debugging doesn’t support Fibers

  • Article

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.

Comments

  • Anonymous
    March 01, 2005
    In one of our applications, we use fibers to implement coroutines. We use fibers instead of threads because we're using single-threaded apartment COM objects from the coroutines and don't want to marshal the objects between threads. Furthermore, we use third-party COM objects that cannot be marshalled in this way.<br><br>Too bad the CLR doesn't support continuations. To convert this application to C#, we'll probably have to roll our own continuations in code in order to eliminate the fibers.
  • Anonymous
    March 01, 2005
    In one of our applications, we use fibers to implement coroutines. We use fibers instead of threads because we're using single-threaded apartment COM objects from the coroutines and don't want to marshal the objects between threads. Furthermore, we use third-party COM objects that cannot be marshalled in this way.

    Too bad the CLR doesn't support continuations. To convert this application to C#, we'll probably have to roll our own continuations in code in order to eliminate the fibers.
  • Anonymous
    March 01, 2005
    The comment has been removed
  • Anonymous
    March 01, 2005
    The comment has been removed
  • Anonymous
    March 01, 2005
    Another BTW: I logged a bug here http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=dcd18227-ab64-4e07-a138-856d8a3aa9f7 the other day. You may want to take ownership of that so that these folks don't burn cycles on it.
  • Anonymous
    March 01, 2005
    SQL Server supports fiber mode and hosts managed code (presumably this is a big reason why CLRv2 supports fibers), so how do they debug if VS doesn't support managed debugging with fibers?
  • Anonymous
    March 02, 2005
    Nicholas - SQL can't run in fiber mode if being managed debugged.
    Albert - I've updated the issue you pointed to.

    Bob - C# in v2.0 added coroutine support for enumerators via the 'yield' keyword. Can you use that?
  • Anonymous
    May 16, 2005
    RePost:
    http://www.yeyan.cn/Programming/ManagedDebuggingFibers.aspx
  • Anonymous
    September 01, 2006
    It's tough to make a client use your API correctly. It's especially tough to get clients to not do things...