Quick question - do you know what to do if my console constantly stalls and I cant get out apart from closing and reopening the console? it happens only when debugger line is activated (import pdb; pdb.set_trace()). Stall is happening once some debugger operation finishes. after I type the next command in the debugger line - i cant hit enter. I can move my cursor in the debugger command line but otherwise it is not responding even to forced keyboard commands Contrl-C. I can only close console and reopen - and even then it takes 10 seconds delay. To do it 50 times - a bit annoying. no answers on internet. did submit feedback to spyder but no answer so far. Any hints you might have?
Related
I am using Goland 2021.3.3. In older versions it used to pop up a confirmation box if a run configuration was already running when the Debug or Run button was pressed. Having been using VS for about 20 years, where the green right arrow meant Continue, I keep hitting it when I mean F9 and losing the place in the debugger. Can this warning a setting I can re-enable or has it just been removed?
Preferences/Settings | Advanced Settings | Confirm rerun with process termination.
During my debugging of code, facing one issue regarding Reset. In debug mode, whenever I am putting breakpoint, after getting hit and clicking on Run (Command), getting Software Reset. This is not occurring, when I am not putting any breakpoint in the code, software runs normally. Also after breakpoint got hit, if I execute software via Step command, then also I am not getting Reset.
As the code Size is very Huge, exactly not getting, where is the problem.
I want to know which line of code getting executed, before reset function is called ?
Is any one knows the answer, they can help me.
Using below environments:
Microcontroller: NXP
Debugger: J-Link
Debugging Software: Ozone Debugger
I ran a training process on google colab yesterday. Now the google colab is showing busy, even after restarting runtime and interrupting execution. I want to stop the current execution. Please help!
Selecting 'restart runtime' from the runtime menu should suffice.
If for some reason that doesn't work, you can drop your current backend and start fresh with a new one by selecting the command 'Reset all runtimes...' from the Runtime menu.
It means that your code is running. You don't need to get panicked. Just wait for your code to complete the execution. Your kernel will become ready to use again after that.
As per your scenario, if it's still busy even after complete execution, you can do as in the above answer (Reset session)
Same problem: stuck with 'busy' and 'reconnecting' status.
'restart runtime' didn't work.
Change GPU/CPU didn't work.
Runtime -> Manage Sessions -> Terminate worked.
When it happens with me I go to google webpage, disconnect my accounts and log in again. Then the colab comes back to work.
After performing: Runtime -> Manage Sessions -> Terminate worked.
I pressed reconnect on the top right and it was worked.
I experienced the same issue.
For me, I reset all runtimes, force quit chrome using the task manager and restarted my computer. Some of these steps probably weren't necessary, but the combination of all of them solved the issue for me.
I'm having a persistent problem with Windows 7 freezing when using R. There is a specific context this happens in:
Using Windows 7 on a desktop machine with multiple displays, and having one or more Rgui.exe sessions running
Connecting to the active Windows desktop session via RDP (remote desktop), which results in resizing the display
Using R while connected via RDP (I'm not sure this step is actually involved.)
Getting back on the desktop machine and using the multiple displays again, which results in another display resizing
Then, I can type into an Rgui.exe window, and can type and edit a command, but when I hit Enter, the entire Windows session freezes, and all I can do is reboot.
This happens to me somewhere around 1 out of 2 or 3 times that I use the computer in the above sequence. Sometimes it works fine, other times it freezes. I've not noticed any pattern. I have not noticed that there is much output in the Rgui window when this happens -- I think it can happen with a pretty fresh session. I say this because there is one other report on stackexchange Windows 7 becomes unresponsive if mouse scroll wheel is used after a simulation in R of R apparently causing Windows 7 to freeze when there is a lot of output in the Rgui window.
Symptoms of the frozen machine are:
The text cursor in Rgui remains at the end of the line, i.e., there is no visible indication that Enter was typed
The mouse pointer on the screen responds to mouse movements (but not clicks) for a few seconds, but then stops responding to anything
The physical mouse and keyboard go dead (i.e., the mouse light on an optical mouse turns off, the caps lock light stops lighting)
The machine continues responds to ping
The machine continues to serve up any shared files and directories
If cygwin is installed and sshd is running, I can start up an remote shell on the machine and it works fine
The machine can be rebooted using a remote shutdown command from another machine
There is no record in any system logs of any problem relating to the freeze, or any event related to R
This has been happening to me for several years now, across multiple versions of R. I am currently using R 3.0.2 and it just happened now. It has happened to me at two different workplaces.
The only thing that I can do to be able to use the machine again is reboot it, either by pressing the power button, or doing a remote shutdown. Ctrl-Alt-Delete on the keyboard has no effect.
If anyone else has encountered this problem and found a solution, I would love to hear it.
I'm debugging some of my code on Visual Studio. This code belongs to a custom Session Provider that I created, and I'm debugging it on my web application launch. It starts initializing my provider, and on that function I have a breakpoint that is being hit successfully the first time. However, that same breakpoint is being hit again, but it has a small blue icon and if you hover over, this message is displayed:
The process or thread has changed since last step
On my research I've found several kinds of answers, from people saying that the breakpoint is hitting a different assembly to some others saying that the breakpoint has been hit from a different thread.
Does anybody know what does this really mean?
When you have multiple threads running the same piece of code and you have a breakpoint there, Visual Studio will stop the execution every time any of those threads hit the breakpoint.
This will happen for every thread, in an unpredictable order.
When you are debugging step by step on your code, another thread can execute the code that you were debugging and hit the breakpoint. Visual Studio will let you know about this by putting that blue circle with the exclamation mark on the next statement arrow.
See more here: Debug Multithreaded Applications in Visual Studio
This icon simply means the breakpoint was hit on a different thread than the last thread you were on. It doesn't affect the program behavior at all.