0

Visual Studio has the capability of inspecting suspended threads and their call stack. Is it possible to inspect a suspended fiber's call stack, given a fiber handle?

The goal is to have more debugging information about suspended fibers (and to satisfy my curiosity).

From my initial searches I do not expect this to be easy (or even doable). Suggestions are welcome.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Selmar
  • 722
  • 1
  • 5
  • 12
  • @ someone who pointed out fibers run in the context of the thread: I realize this. However, fibers store their own state. When any (fiber-enabled) thread schedules a fiber, it is able to show me its call stack. This leads me to think that, from the state stored by the fiber, it should be possible to display the call stack. – Selmar Jan 16 '20 at 09:33

1 Answers1

-1

no, this is not possible. debugger can not get stack for not active fibers simply because only application itself know where inactive fibers data and stack located.

try explain.

given a fiber handle?

not exist handle for fiber. exist handle only for thread. and stack for active fiber - tis is the same as thread stack. additional fibers (and it stack) allocated from process heap. os not store - where additional fiber data/stack located. application itself must store this info. external programs, include debuggers, can not know this. as result - impossible show stack trace, if we even dont know where it located. debugger even can not know - how many fibers exist. possible only view - are fibers (how minimum one) active on thread (after call ConvertThreadToFiber and before ConvertFiberToThread). are additional fibers created, where it data/stack stored - already unknown.

RbMm
  • 31,280
  • 3
  • 35
  • 56
  • With fiber *handle* he most likely means the fiber address returned by `CreateFiber`, and in there the stack pointer is saved. With this information it is possible to find out the fiber call stack in the debugger, if you replace rsp/rip of some thread with the values of the fiber (which obviously need to be restored afterwards). – ssbssa Mar 21 '20 at 15:22
  • @ssbssa - debugger can not got address returned by `CreateFiber` – RbMm Mar 21 '20 at 15:37
  • No, but you can have this address stored in some variable. – ssbssa Mar 21 '20 at 16:28
  • @ssbssa - for have this address in another process (debuger or any) need set hooks `CreateFiberEx`, `CreateFiber`, `DeleteFiber`. only special design for this tool can do this, but not general debugger. *you can have this address stored in some variable* - i can not understand this at all – RbMm Mar 21 '20 at 16:32
  • You're thinking too complicated. The problem isn't getting the fiber address, you can just assume that you already have it. That was part of the question: `given a fiber handle` – ssbssa Mar 21 '20 at 18:02
  • @ssbssa -*you can just assume that you already have it.* no, we can not assume this. we have not this (if not set hook in target process). and i dont know any debugger, which do this – RbMm Mar 21 '20 at 19:49
  • 1
    But we can assume here that we already have the fiber address, because it's written so in this question: `Is it possible to inspect a suspended fiber's call stack, given a fiber handle?` – ssbssa Mar 21 '20 at 21:02
  • @ssbssa - yes, if we have address of fiber (not exist any handle for it), it possible if use **internal** (not documented) format of fiber structure. not exist api for do this – RbMm Mar 21 '20 at 21:08
  • Yes, and I think he basically wants to know where in the fiber structure this information is stored (and maybe also if it is the same for all Windows versions). – ssbssa Mar 21 '20 at 21:12
  • @ssbssa - for this need ask another question. information about stack pointer of course stored, another question that this is internal data and where it stored can change – RbMm Mar 21 '20 at 21:15
  • I was hoping there would be some tools for this, given the fact that windows fibers are quite old and thread debugging is an integral part of visual studio. Picking apart the internal structure of the fiber API seems a bit tricky, I think in this case I'm better off writing my own fiber API or using Boost's, then adding debugging on top of that. Thanks for the insights! :) – Selmar Jun 18 '20 at 10:53
  • @Selmar impossible write any tool for this. simply because impossible get pointer to inactive fiber – RbMm Jun 18 '20 at 10:57