Add stack frames to debugger call stack

[AL4AL]

I tried calva debugger in metabase project, wherever I pause the application by Instrumenting top level form for debugging, It pauses and everythinks works as expected but call stack, code is paused in a function and I know there are at least more than 3 files involved and many functions has called each other until they have reached this function but call stack only shows current function:

While I want to know who called this function

[bpringe]

Thanks for reporting this. I'm not sure if this is a limitation of cider-nrepl's debugger or just something I overlooked when implementing. I'll have to look more into it.

[bpringe]

It does indeed look like I just overlooked this 😄. I admittedly don't use the debugger much, so your feedback is helpful. I think I can improve the call stack fairly easily, though it may be a little time before I can complete this.

[bpringe]

I've noticed stacktraces don't have a source file for frame involving the call site. For example in the below image, if I eval the top level form at line 116, the frame for that call in the stacktrace will not have a source file.

I think this is because we're not passing file info to the nrepl eval op here:

calva/src/nrepl/index.ts

Line 307 in e4e20da

this.client.write(opMsg);

We pass the info to the eval function, but it's not used in the op. I think if we send that with the op then the stack traces will contain the info.

CC @PEZ. I'll try this out when I get back to this.

[bpringe]

You can see this in this stackframe here:

I eval'd the call to f in the image in the comment above at line 117, and you can see NO_SOURCE_FILE for that frame in the stacktrace in the output window. I hadn't really paid much attention to that before, but now it's needed to make the stacktraces work well with the debugger.

[bpringe]

My mistake, apparently we are sending line, column, and file to the nrepl op. I wonder why nrepl gives us NO_SOURCE_FILE for those frames then.

[bpringe]

A friend verified for me that in Cider this is also the case.

Calva:

Cider:

[bpringe]

@AL4AL Check out the latest version of Calva. You should see more stack frames in the call stack now. Let me know if you have issues.

[bpringe]

This was rolled back in 2.0.205. See #1236 and #1210.

The issue seems to caused by changes made to stackTraceRequest (see the changes in #1151), so this the place to look for a fix. I'll get back to this later, but in the meantime if anyone else wants to pick it up, please comment here so I know.

[bpringe]

I've decided to not spend more time on this feature, at least for the foreseeable future. After watching "Victim's of Complexity" by Bozhidar Batsov, re-evaluating the time I have to spend on Calva with respect to more recent work commitments, and re-thinking the way I approach Calva maintenance and development, I'd like to spend the time I have on:

• Bug fixes
• Documentation
• Features I will personally use
• Features that are requested by or that we feel will benefit many Calva users

I did work on this a little bit and below are my notes for anyone who may want to pick this up.

---

Reproduction

0. Jack in (the next steps should happen after a fresh jack-in)
1. Instrument a function for debugging
2. Call the instrumented function
3. See the debugger step buttons are disabled.

At this point, I find that if I disconnect the debugger by clicking the disconnect button, then call the function again, the debugger works fine.

Notes

• When I add await cljSession.sendDebugInput(':stacktrace', id, key) to the stackTraceRequest function the problem occurs, even without adding the other code that uses the result of that call
• If I add the call to await sendDebugInput to the attachRequest function, then two duplicate Calva Debug stack traces show up in the call stack pane.
• I think perhaps a bigger issue, that may be related, is that two debuggers are started as mentioned above. In the linked PR I added logging to get a better picture of what was happening, and you can see that the CalvaDebugSession constructor is called twice. IIRC this happens even with the debugger in its working state, without adding the code mentioned above that causes two stack traces to show in the call stack pane.

  DEBUG:CalvaDebugSession constructor called
  DEBUG:handleNeedDebugInput called
  DEBUG:Calling startDebugging
  DEBUG:resolveDebugConfiguration called
  DEBUG:Creating a new DebugAdapterServer
  DEBUG:Creating a new CalvaDebugSession
  DEBUG:CalvaDebugSession constructor called
  DEBUG:initializeRequest called
  DEBUG:attachRequest called
  DEBUG:running onDidStartDebugSession
  DEBUG:Custom request called: sending StoppedEvent
  DEBUG:threadsRequest called
  DEBUG:stackTraceRequest called
  DEBUG:scopesRequest called
  DEBUG:variablesRequest called
  

  • This could be caused by some issue in the way we start the debugger, and this guide could be helpful in fixing the issue: https://code.visualstudio.com/api/extension-guides/debugger-extension