I am using Visual Studio Code with the Julia plugin. Regular debugging is impossibly slow, so I a tried to use the package Infiltrator.jl. I insert #infiltrate where I want execution to stop, just like a breakpoint and then start the REPL. Execution indeed stops there and the REPL prompt changes to yellow infil>. So far so good, but when I type something the letters get scrambled, sometimes when I hit Enter and sometimes even before that. It happens before my eyes. After two or three attempts the REPL prompt changes back to green julia> and the REPL freezes.
Anyone familiar with this problem?
As per the readme:
Running code that ends up triggering the #infiltrate REPL mode via inline evaluation in VSCode or Juno can cause issues, so it's recommended to always use the REPL directly.
Related
I would like to debug a C++ program in VSCode. The problem is this program is run as part of a large and messy build system that spawns many processes and prepares input for the program. In other words if I run:
./do the_task
It will compile a load of C++, generate some input and eventually - through several layers of Bash, Python and Makefiles - run something like this:
/very/long/path/to/the_task --lots --of --arguments /very/long/path/to/generated_input.xml
I'd like to debug that process using VSCode/GDB, in such a way that I can
Set breakpoints in the_task.cpp
Just click "Start debugging" with the launch.json set to run do the_task
Unfortunately that doesn't work because by default GDB doesn't follow child processes. You can tell it to but then it will halt the parent process so that only a single process runs at a time. That causes everything to get stuck at some point in my case.
Some ideas I've had:
Is there a way to tell GDB to run a script when a new inferior (process) starts, check the executable name and then detach from the child if it doesn't match?
I could create a proxy GDB/MI wrapper that pretends to VSCode that the program has been started (so the connection doesn't time out), and then when we get to running /very/long/path/to/the_task prefix it with gdb --interpreter=mi and forward on all of the cached commands (to set breakpoints etc.) This seems like quite a lot of work and quite hacky so I'm not sure I like it.
Prefix /very/long/path/to/the_task with gdbserver. Then I can connect to it from VSCode. This is definitely the simplest and most obvious solution but the UX sucks - you have to manually start the command, then wait, then click "start debugging". Plus you're inevitably going to run into port reuse annoyances.
3, but write a custom VSCode extension that automatically starts debugging when it detects gdbserver has started. I've done this for Python debugging so it does work but there are some minor annoyances (e.g. if you restart VSCode and it restores a terminal session it doesn't work). Also it's a fair amount of work.
Is there an obvious solution I'm missing?
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I have recently been having a problem which essentially makes debugging Go using delve next to impossible. Basically I can't use breakpoints otherwise there is a good chance the debugged code freezes and all I can do is stop the debugger an restart.
To start at the beginning... I have had an intermittent problem debugging Go using GoLand IDE (2019.1) and delve (1.0.0-rc2) for some time. The whole session would freeze - I know that nothing is happening because the debugged process CPU usage is zero, and the fact that there are no messages being written to the log (I have many go-routines most of which are writing occasional log messages). It's as if a breakpoint was hit but the debugger commands (STEP, etc) are not enabled which indicates that the debugger is not at a breakpoint. When this happens I have to hit the GoLand STOP button twice to get the debugger to terminate and then start all over again.
Recently this problem has become far more common. From perhaps a few times a day to almost every debug session. This is annoying but at least it has allowed me to track down what I believe is the underlying problem. It seems that sometimes when a breakpoint is encountered the debugger stops but delve or the IDE does not realise that - so there is no way to continue.
How do I know this? I proved this to myself by setting a breakpoint on a log line (ie, log.Printf). When the breakpoint is on that line (and I know it will be hit) then the debug session freezes. If I ensure there are no breakpoints that will be hit then the program runs absolutely fine including printing the log line. If I set the (one and only) breakpoint on the line after log line the log line is printed and the session freezes.
I think this is a problem with delve. Note that I have loaded the same project into VSCode and the exactly the same thing happens (GoLand and VSCode use the same version of delve), so I don't think GoLand is doing anything wrong. But if someone has another explanation I welcome it.
I have tried a lot of things to track down the cause. I have created a small project in order to demonstrate the problem but it does not occur in a simple project. It appears that I am doing something wrong (in my large project) that causes delve to misbehave but I have no idea what that is.
First, 1.0.0-rc2 seems anvient forn Delve: the current version is 1.2.0
1.0.0-rc2 is so ancient that a similar bug was reported in August 2018 (issue 1318) regarding an headless execution of delve:
dlv debug --headless ...
Adding --log --log-output=rpc can give you additional clues.
dlv debug --headless --listen=:2345 --api-version=2 --log --log-output=rpc ./test.go
Delve itself, in headless mode, will ignore SIGINT.
To stop the headless instance you have to connect to it and then terminate the connection.
To send a SIGINT to the target program you have to start the target program, which you didn't, because to start the target program you have to connect to delve first.
I am new to Ruby so have installed RadRails, Ruby 1.92 and ruby-debug-ide19. I have a very simple ruby program that prints hello world. But when I try and place a breakpoint in the code and run in debug mode all i get is the following line on the console:
Fast Debugger (ruby-debug-ide 0.4.9) listens on :51224
Why does it need to listen on a port anyway? And how can i get it to run my program until the breakpoint?
Personally, I don't bother with an IDE for debugging. I prefer to be closer to the metal... err... command-line, so I use ruby-debug19 from the command-line.
rdebug some_file_to_debug
For the basics use:
b to set your breakpoints
n to step over methods
s to step into methods
c to continue running after hitting a breakpoint
c n to run to a particular line then stop
p to display a value
h will display the built-in help
irb drops into IRB with the current variables pre-initialized so you can poke at things with a stick and see what they'll do.
More docs are at the Ruby-Debug site.
It uses the port to communicate between the IDE and the ruby-debug process, ruby-debug-ide is opening a port and waiting for the IDE to connect to it, but that happens pretty must instantly.
From what you've stated, debugging should already be working: You can right-click and select Toggle breakpoint, or double-click on the left-hand gutter of the editor. When your program hits any enabled breakpoint line the program should suspend and you can inspect variables, the stackframes, execute arbitrary code, step into or through your code, continue, etc.
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.