I didn't change any configuration settings, but python debugger in vscode malfunctions.
When I use breakpoint() explicitly, it works,
but when I use F5 to start debugging, it automatically ends without any execution.
I googled all the spaces, but I cannot find the reason why debugger does not work.
(It originally worked.)
I sincerely need your help.
Related
My task is to repeatedly rerun a code from beginning. As I do not want to run the code to the end I set a breakpoint() command. However, Spyder freezes when the code is the second time called from debug mode. For demonstration a simple program is sufficient:
print('Hello World!')
breakpoint()
After launching Spyder I start the small program by F5. Everything works as expected and I jumped into the debug mode. Now I press again F5 and the code restarts correctly from the debug mode. After again pressing F5 the code is not restarted and instead the IDE freezes. It is not possible by any means to rerun the code again from debug mode. Interrupting the kernel by pressing the red button (see screenshot below) does not help. Trying to leave the debug mode by !q does not leave the debug mode. The only possibility to rerun the code is quite cumbersome, i.e. I have to restart the kernel (Ctrl+.) that takes a while. How to debug code under these circumstances?
Is this a bug of the IDE or expected behavior? How can I restart the code by a simple key press as often as possible from debug mode?
This is a screenshot of the Spyder console with comments in red added.
I use a recent version a WinPython with latest Spyder 5.4.0, Python 3.10.4 64-bit, Qt 5.15.2, PyQt5 5.15.6, Windows 10Pro Version 21H2. The problem also appears with Spyder 5.3.3 A similar problem (or maybe the same) appears with a different Python version.
After many trials, I noticed that there is something strange with IPython console. I noticed that when it hangs after running a code, if I delete all user variables, it worked fine.
Then I tryed to delete all variables before execution, and it work fine.
Therefore I discovered that a solution that worked for me is to go to preferences -> Run -> and untick the option 'Remove all variables before execution'
It is quite annoying because I have to do it manually every time before running, but in this way the spyder does not appear to hang anymore! I hope that the Spyder developers will solve it soon.
-
I automatically solved by typing at the beginning of any script these lines, inspired from the question Code to clear console and variables in Spyder :
try:
from IPython import get_ipython
get_ipython().magic('clear')
get_ipython().magic('reset -f')
import matplotlib.pyplot as plt
plt.close('all')
except:
pass
similar to Matlab in which you normally start your code with
clc
close all
clear all
I use ZeroBrane studio (ZBstudio) for debugging Lua code when working with the Torch framework.
A weird issue occurs at times. When debugging, sometimes I want to run the code all the way until it encounters a breakpoint. This specific mode does not work at times (sometimes it does, sometimes it doesn't; I can't figure out why).
When it doesn't work, nothing happens when I press the relevant button in the GUI (or Ctrl+Shift+F10). I can go line-by-line (Shift+F10) when this happens, the line-by-line mode is not affected.
Sometimes when this happend, restarting the ZeroBrane IDE program fixed it, other times it remains persistant.
Not sure if anyone else encountered this strange behaviour. Thanks in any case.
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I have an app built in node.js and I use the node inspector in order to debug.
But it's quite hard because of this:
My breakpoints are never saved after I restart the server
I cannot put a breakpoint on a file that has not loaded yet; so I have to step into from the first script to the one I want; REALLY PAINFULL!
How do you really debug node.js with node inspector?
The videos on how to use node.js are quite misleading as everything is into a module...
http://www.youtube.com/watch?v=AOnK3NVnxL8
or this one the scripts appear are already loaded in the first script
http://www.youtube.com/watch?v=HJOH0-g8f6E&feature=mfu_in_order&list=UL
Edit:
Nobody can answer this question? :s
In javascript you can set breakpoints using the debugger; statement. However, they will only pause node if a debugger is actually attached.
So launch your node script using
node --debug-brk myfile.js
then launch node-inspector and press the play button to continue to the next breakpoint and it will hit your debugger; breakpoint (at least that works for me ATM)
(as noted in the comments: in recent versions of node you no longer have to separately install node-inspector. If you launch node using node --debug-brk --inspect myfile.js you get a url that launches the debugger in your browser).
you still need one extra click after restarting, but at least your breakpoints are saved.
if your breakpoint is not hit automatically, but only after some user action you don't need the --debug-brk of course.
The problem with client-side breakpoints is that it's hard to keep track of the breakpoint position when the file changes. Unlike in an editor, it cannot keep track of lines being changed, etc.
#RyanOlds suggestion of using debugger; statements is also a good one, but you have to make sure the debugger is connected before the statement is evaluated, because it is ignored otherwise. Starting with --debug-brk is a good way to force this, because the execution is paused on the first line allowing you to attach the debugger and then continue the execution.
You could try debugging with node's internal debugger.
Edit: However, according to the v8 DebuggerProtocol it's possible to set breakpoints on script that hasn't been loaded yet AND you can set breakpoints by function, script and more. It should therefore be possible for node-inspector to keep track of your breakpoints (in a session, or whatever). It doesn't do so right now, though.
Maybe if v8 allows a certain piece of code to trigger a breakpoint, similar to nodes debugger?
Edit: It does, you should be able to trigger a break by throwing any old exception (caught or uncaught).
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.
https://github.com/node-inspector/node-inspector/pull/116
Try using IntelliJ WebStorm - there's a free trial and licenses aren't outrageously expensive. It lets you save breakpoints in all your files prior to starting up its own internal node process and remembers them across process restarts.
I agree - node-inspector looks brilliant, but is quite useless unless your app has a clear place to set a breakpoint in the top level script just after your source files have loaded, but before you hit the area you want to debug. You can structure your own code this way, but you won't be so lucky with other helpful libraries you want to include. Also... why should a debugging tool dictate your project structure!
Forgetting breakpoints is extremely unhelpful... most of my debug runs take more than one walkthrough, as in other people's code it's easy to step past where you want to be.
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.
https://github.com/ketamynx/node-codein/
Also worth noting.. vscode has a great debugger for node.
https://code.visualstudio.com/
Available on Mac, Linux, & Windows.
It does runtime breakpoints (without the need of writing debugger; statements),
supports variable watches, and even has a call stack window (very nice).
Everything is so automated, it is now my goto over sublime text when using nodejs (and I LOVE sublime).
This is built in now including saving breakpoints. I just tested it in node 7.3.0.
node --inspect --debug-brk app.js
This prints a url like this
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/c3d5d93e-9d27-41b9-a4da-607e43c9d4f8
Put that in Chrome and you're good to go.
If you want to skip copy/pasting the url, do this:
npm install -g inspect-process
inspect --debug-brk app.js
Unfortunately the inspect-process method doesn't retain the breakpoints :-(.
Here's a video I made: https://youtu.be/rtZKUnks6jI
I am scripting Illustrator CS5 with the Extendscript Toolkit.
I set several breakpoints in my code, they show up as red dots next to the line number. But when I run the script, it executes all the way to the end without stopping and the breakpoint dots turn dark.
What am I missing here?
Thanks!
Check to make sure $.level isn't set somewhere, either in your code or the app's startup script. If $.level is set to 0 or 1, breakpoints are disabled. You might also try explictly setting $.level=2 at the start of your code, to ensure breakpoints are turned on.
This is a common error in the ESTK (Extendscript Toolkit), I believe it's a bug - breakpoints should not get disabled by starting the script.
Most likely pressing F11 (step into) will also make the breakpoints turn into a darker red colour (disabled). But in this state (stepping through the code) you can enable the breakpoints again and they will get hit when you let the script run on (F5).
(Shortcuts are for the Windows version.)
Another thing to try is to first start the script from the scripts panel in InDesign (run it once), and then start it from the ESTK. If you use the targetengine directive to set a specific engine name, this might even be necessary.