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?
Related
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.
I am trying to debug Assembly x86 in Visual Studio Code but all the stepping buttons are disabled
I am using this extension https://marketplace.visualstudio.com/items?itemName=DamianKoper.gdb-debug
I am using Windows 7 and i have installed gdb with Msys
This is launch.json :
{
// 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": "gdb",
"request": "launch",
"name": "GDB",
"program": "${workspaceFolder}/${command:AskForProgramName}",
"stopOnEntry": true,
"arguments": ""
}
]
}
Have had the same issue with GDB Debug extension in VS Code (WSL2), also tried change configs with no result. Anyhow, this extension and similar extensions (like Native Debug that allowed me to make breakpoints with proper config) are not so useful. There is no register view and memory view that are crucial for asm debugging. I assume VS Code is not good for asm, and for Windows your best bets are QtCreator (includes asm debugger with registers, etc) and MS Visual Studio. Another option is GDB in TUI mode from the terminal (gdb ./exefilename -tui), but GDB with its number of commands has a steep learning curve.
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!
Using Debugger For Firefox in VS Code, and running an instance of LiveServer for my HTML/JS application on localhost, breakpoints do not work when opening the site in Firefox or Firefox Developer Edition.
VS code has generated the launch.json for debugging in Firefox for my project, with the relevant part here:
{
"name": "Launch localhost",
"type": "firefox",
"request": "launch",
"reAttach": true,
"url": "http://localhost/index.html",
"webRoot": "${workspaceFolder}"
},
The issue is that when I then run this setup, Firefox cannot find the page, and even if it does, breakpoints do not work. The equivalent of the above for Chrome works, however.
I resolved this issue by changing the settings on LiveServer so that it always works on localhost port 8080, it won't just chose a random port when its active. This can be done by adding the following to LiveServer's settings.json file:
"liveServer.settings.port": 8080,
In the launch.json code included in the above question, the following line is causing the issue:
"url": "http://localhost/index.html",
This should instead be
"url": "http://localhost:8080",
Once this change is made, and all the Firefox configurations suggested under 'Attach' on this page are made and LiveServer is active for your project, the debugger should work for Firefox.
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.