Load call stack for all threads

[kuznetsss]

Hi, thanks for the amazing plugin!

When I debug a multithread application I can see call stack only for the currently stopped thread. nvim-dap has an option auto_continue_if_many_stopped which if I understand it correctly controls whether all threads should be paused on a breakpoint or only the current one. So if I put this option to false it would be useful to see a call stack for all threads. Maybe if it is complicated to detect it from nvim-dap automatically there could be an option whether to load a stack for all threads or not.

[sleeptightAnsiC]

I'm not entirely sure about it but I think this feature was actually working in the past or that it's already implemented but not enabled by default. I remember seeing this working like half a year ago but right now I'm also struggling with the same issue. According to https://github.com/mfussenegger/nvim-dap/discussions/284#discussioncomment-1247498 the functionality was already there back in 2021.

In fact, if you open dap-repl, type .threads, hover the thread and expand it with <CR>, and then hover any frame and open it with o, it will cause said stack trace to appear in DAP Stacks like so:

[sleeptightAnsiC]

I just bisected this and I can confirm it's a regression most likely caused by https://github.com/rcarriga/nvim-dap-ui/commit/a62e86b124a94ad1f34a3f936ea146d00aa096d1 / https://github.com/rcarriga/nvim-dap-ui/pull/307 :

a62e86b124a94ad1f34a3f936ea146d00aa096d1 is the first bad commit
commit a62e86b124a94ad1f34a3f936ea146d00aa096d1
Author: Rónán Carrigan <[email protected]>
Date:   Sat Jan 20 15:46:04 2024 +0000

    fix(frames): use session's frames

    See #303
    Closes #307

    Co-authored-by: przepompownia <[email protected]>

 lua/dapui/client/init.lua       | 2 ++
 lua/dapui/components/frames.lua | 9 ++++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

Hey @kuznetsss, if you need this functionality right now, you can easily rollback to last good commit https://github.com/rcarriga/nvim-dap-ui/commit/0b4816e5ad5f3219e8e3ec9cce07f61b770c1974 via your plugin manager. I can confirm said commit works fine on my side (screenshot below for proof). Though, fetching frames for every thread might be a bit slow if you're debugging something huge. Perhaps, it would be nice to have a toggle option for this feature.

Hey @rcarriga, @przepompownia, Tagging since this might be trivial for you to fix with the info I just provided.

[przepompownia]

Hi @kuznetsss @sleeptightAnsiC

The mentioned change is apparently happening within a single thread just like before so I wonder how it might impact rendering other threads.

On the other side, I did not test my proposal with multi-threading and still have no idea how to make a minimal repro to see what happens in such case.

[kuznetsss]

Hi @przepompownia, would you be ok with a minimal multithread C++ example?

[przepompownia]

Do you mean a complete repro that starts automatically, for example similar to https://github.com/przepompownia/nvim-dap-ui-current-frame-bug (at the moment not minimal relative to the original problem)?

[kuznetsss]

I mean I could provide a simple C++ or Rust code and instructions how to compile and run debug on it. Self starting repro looks a bit complicated for me, but maybe still possible.

[sleeptightAnsiC]

@przepompownia,

The mentioned change is apparently happening within a single thread just like before so I wonder how it might impact rendering other threads.

The function from frames.lua runs for each thread and since you've changed how frames are being fetched this is most likely what broke it.

I think, it will be faster if I'll just try to fix it instead of wasting time on providing repro. Gonna give it a try in a moment.

[sleeptightAnsiC]

Ok, I just got this working with the patch below. Still testing it though.

Does the DAB Stacks window looks right to you? @przepompownia I'm worrying that I might cause https://github.com/rcarriga/nvim-dap-ui/pull/307 to reoccur with the patch. Not sure if I understood it right.

I'm also worried that both threads have name main (but this might be an issue with debug adapter)

diff --git a/lua/dapui/components/frames.lua b/lua/dapui/components/frames.lua
index 723d8ec..c6f6d8c 100644
--- a/lua/dapui/components/frames.lua
+++ b/lua/dapui/components/frames.lua
@@ -12,9 +12,11 @@ return function(client, send_ready)
     ---@async
     ---@param canvas dapui.Canvas
     render = function(canvas, thread_id, show_subtle, indent)
-      if not client.session then
+      local success, response = pcall(client.request.stackTrace, { threadId = thread_id })
+      if not success then
         return
       end
+      assert(client.session)
 
       local current_frame_id = nil
 
@@ -24,10 +26,11 @@ return function(client, send_ready)
         return
       end
 
-      local frames = threads[thread_id].frames
-      if not frames then
-        return
-      end
+      local frames =
+        false
+        or threads[thread_id].frames
+        or response.stackFrames
+      assert(frames)
 
       if not show_subtle then
         frames = vim.tbl_filter(function(frame)

[sleeptightAnsiC]

Works fine on my side but I changed the patch a little bit: https://github.com/rcarriga/nvim-dap-ui/pull/395 @kuznetsss Could you check if this works on your side?

[kuznetsss]

@sleeptightAnsiC, thanks for the fix! I can confirm it works with lldb-vscode.

[przepompownia]

I mean I could provide a simple C++ or Rust code and instructions how to compile and run debug on it. Self starting repro looks a bit complicated for me, but maybe still possible.

On the other side I'd need some time to learn basics of debugging code in those languages. Finally, nice to see that you've proposed some working patch. It doesn't break the fix from a62e86b1 for me, at least in the scope I see on the PHP example.

@sleeptightAnsiC, @kuznetsss could you check on #395 if highlighting the current frame still works after switching between threads?

[sleeptightAnsiC]

@przepompownia Seems fine on my end, unless I'm missing something. Take a look:

https://github.com/user-attachments/assets/60961e84-81a5-4af3-86fa-1b0073bf8959

[przepompownia]

@przepompownia Seems fine on my end, unless I'm missing something. Take a look: 2024-08-30_13-18-00.mp4

Both threads look highlighted (only by horizontal arrow for your colortheme): thanks for checking and the screencast.

[shmerl]

FYI, the fix for this introduced a regression.

See #418