Confused by vscode delve debugger - go

I have searched everywhere and tried what I can, but debugging go exes in VSCODE is just acting really weird for me.
If I step through code, the debugger seems to jump around all over the place sometimes, as though I was switching threads. Most of the time if I hover over variables nothing happens. If I try to add them as watches I just get "unavailable". I am building and running from within the IDE.
I have the latest version of go and delve. I see that I should be avoiding compiler optimisations with some gcflags settings, but nothing doing. No idea how to make progress. Any clues?
UPDATE: After all, this was simply a typo in the build task used by VSCODE. The problem indeed was compiler optimisations, which needed to be disabled using the following exact syntax:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Make Prog",
"type": "shell",
"command": "go",
"args": [
"install",
"-gcflags",
"-N -l",
"./..."
],
"group": {
"kind": "build",
"isDefault": true
},
}
]
}
Relevant too is that I am using "exec", not "debug", to debug the executable.

Delve enables you to interact with your program by controlling the
execution of the process, evaluating variables, and providing
information of thread / goroutine state, CPU register state and more.
Delve will compile the 'main' package in the current directory, and begin to debug it.
For your question:-
If I step through code, the debugger seems to jump around all over the
place sometimes, as though I was switching threads
Suppose you have a code in which an error occurs and your code panics then VSCode will make you jump to the panic definition defined in its core files when debugging the code.
For your second question:-
Most of the time if I hover over variables nothing happens. If I try
to add them as watches I just get "unavailable".
Vs Code can only provide you the definitions of those functions which are defined in same package, So if they are defined in another package then you have to import that package, else it will show you unavailable function definition. So check for proper imports where unavailable is showing on hover.
For more information Check usage Documentation for Delve Debugger
Edited: Even if It jumps when using F10, Create breakpoints after the code where it jumps and use F12 to jump to next breakpoint, that way it will not jump to a core function definition.

Related

How to get VS Code to scroll to source line when breakpoint hit

When VS Code encounters a breakpoint that pauses the program, I expect the source file to be opened and the exact line of execution scrolled into view. This used to work, but it has mysteriously stopped. I have searched for a setting using words like "breakpoint", "debug", and "scroll" but have had no luck.
This seems to be happening only for my golang project, as the expected breakpoint behavior happens in a python project. I am running VS Code Go Extension v0.37.1, VS Code version 1.75.1.

Can I avoid debugger to stop in assembly code?

I'm debugging some Rust code and it pass throw places like:
I think this is some assembly code from rust libraries.
Is there any way to avoid to stop here? And just go throw readable code?
I already unflagged the option
Disassembly View: Show Source Code
Show Source Code in Disassembly View.
My launch.json is a very default one:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "launch",
"cargo": {
"args": [
"build",
"--bin=myproject",
"--package=myproject"
],
"filter": {
"name": "myproject",
"kind": "bin"
}
},
"args": [],
"cwd": "${workspaceFolder}",
"env": {}
}
]
}
I note that the picture you posted shows Local Variables for self and cx in the Locals window. If that Locals window is for the current frame - the one showing assembly instead of source - then you must have debug info for that frame (*).
If that's all true, it's much more likely be that you just don't have a local copy of the source files for this function. Maybe you downloaded a debug version of the rust standard libraries and that's why it has debug info? You can tell for sure by running the command:
(lldb) image lookup -va $pc
when stopped here. If there are entries for CompileUnit and Function, etc. then you do indeed have debug info for this frame.
All of lldb's tests for "don't stop in code with no debug info" are about the presence of debug info, not whether we can find the associated sources. So if you have debug info for a function, and your program gets into that function in the course of stepping, lldb will stop there.
You can modify this behavior on a library by library basis by adding the library name to the lldb setting target.process.thread.step-avoid-libraries. It's a colon separated list of library names or paths. If a step (but not step-instruction) operation ends up in a library on that list, lldb will step back out again regardless of whether it has debug info or not - which is I presume the behavior you want.
Alternately, if you want to step into this function provided you can see the sources, you can surely download the sources for the rust libraries that match the ones you have installed. You will likely also have to use the target.source-map setting to tell lldb where the sources are on your local system.
(*) Note, local variables can show up in non-debug functions if you have a "frame recognizer" registered for that function. lldb has no built-in recognizers for Rust, so you would have had to add that by hand which makes this possibility unlikely. It doesn't sound like you were doing special things for this function.
If you're using the extension CodeLLDB, you can disable this code break by going into File -> Preferences -> Settings (Ctrl+Comma) and under Extensions -> CodeLLDB select the option "never" under Lldb: Show Disassembly.
For me, this stopped the debug session from going into the assembly code. For example, if my assert!() had an error the session would exit rather than stopping in the assembly code first and then exiting.

VS Code debugger toolbar buttons disabled during debugging session

I am a beginner C programmer. Currently, I have Visual Studio version 1.61 September 2021 installed
on my windows 64-bit system. I also installed MingW64 and set up the environment variables to compile and debug with the purpose of writing, debugging and running my c programs.
I have been able to write and run my programs without any issues. I did notice that whenever I wish to debug my program, the debug toolbar that hovers on top has the buttons disabled and no line is pointed by the "yellow arrow".
I modified the "launch.json" file where I set the following:
"stopAtEntry": true,
This set the yellow arrow to point at the beginning of the program instead of the breakpoint and the debug toolbar buttons were activated. Though whenever I step-over on to the next line of code, the yellow arrow disappears and the debug toolbar buttons are deactivated once again.
This happens often on lines where I assign values to variables.
I am a beginner and I find VS Code quite frustrating, I would appreciate your input and suggestions. Thanks
UPDATE: I solved it.
So it turns out that there is nothing wrong with my debugger and it was behaving as it should. I noticed that it would always fall into that behavior whenever the gcc compiler was to execute the line including scanf(). The registers and variables in the watchlist would suddenly become "unavailable" this is because the compiler was waiting for user input.
Since VS Code did not show the running program on PowerShell, I modified the "launch.json" certain configurations to the following:
"externalConsole": true,
This allows for Command Prompt to open up, display the running program and allows for user input.
Once the user input is received the debug toolbar buttons are activated again and I could continue debugging. The watchlist variable also become available to analysis.
"stopAtEntry": false,
I set this configuration to false because I did not wish for the debugger to begin at the beginning of the program.
This was certainly frustrating but after finding the solution to this "issue", I bet that my endorphin and oxytocin levels are off the charts.
Very thrilling, this is what I love the most about problem solving.

Empty debugger with Ada in VSCode (MacOS)

I am experiencing a weird issue with the Debugger on VS Code, I am following this guide: https://github.com/AdaCore/ada_language_server/wiki/getting-started but can't make it work at all. I have installed the Native Debug extension, gdb is installed...etc. I have been working with Ada for some time but just thought about starting to debug my projects. I am first trying to make it work with a simple project hello_world, like explained on the guide.
I can start the debugger, but it won't show anything, not the variables or the call stack, nothing - just which breakpoints I did toggle. The controls that allow you to step through the code are also empty, as you can see here: https://i.stack.imgur.com/eJ7dC.png
The content of my launch.json is:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "gdb",
"request": "launch",
"target": ".objs/hello_world",
"cwd": "${workspaceRoot}",
"valuesFormatting": "parseText",
"preLaunchTask": "ada: Build current project",
}
]
}
The rest are also the same than the guide's. Any help would be greatly appreciated! I am a bit lost and don't know what to do.
Thank you.
Edit: Just in case, I did it everything from scratch again, same result. Can't achieve to make it work, debugger controls and variable/watch windows are always empty.
Any ideas?
Thanks!

Parcel debugging experience inconsistent

I have a rather simple setup:
- parcel 1.12.4
- vs code 1.43.2
- chrome 80.0.3987.149 on macOS
- chrome debugger extension
- node v13.11.0
- a simple index.html that uses main.js which imports moment.js and a module of mine.
Snippet from launch.json
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome",
"url": "http://localhost:1234",
"webRoot": "${workspaceFolder}"
}
When I serve everything via parcel index.js it compiles and runs fine.
When I set a breakpoint in main.js , it is grayed out and ignored.
When I resort to debugger;, this breakpoint works and I can also set other breakpoints via VS Code or Chrome.
Most of the time, the breakpoint shows up in a tab main.js read only inlined content ... – the extract of the sourcemap/bundle which is a bit weird but understandable.
Sometimes the breakpoint shows up in dist/main.fb6bbcaf.js, essentially forcing me to debug inside the generated bundle.
This is a bit inconsistent and I did not find any pattern what happens when. I plan to use parcel/javascript with a number of students and I anticipate that they will be confused.
What can I do to get a more consistent debugging experience?

Resources