I was trying to debug a Python program using PyCharm's debugger and each time I resumed execution after hitting a breakpoint my program exited with an obscure error (this particular program is based on Twisted and the error was about not being able to stop an already stopped reactor). The program ran fine within the debugger as long as I didn't stop it with a breakpoint, and it ran fine outside the debugger.
This problem started occurring sometime in the last weeks/month, but in the past I have been able to debug this same program without issue.
It turned out that I just had a function call expression in the PyCharm debug pane that was getting evaluated whenever I hit a breakpoint and that function had a nasty side effect. It was left over from a debugging session several weeks ago related to a shutdown problem (so it kind of makes sense). I pulled a small amount of hair over this, and didn't find anything with google, before I noticed the problem. I hope someone else can learn from my mistake.
Related
Something went wrong on one of my last debug session with Google Apps Script (don't know what). Since then, I'm not able to run a debugger anymore. The debugger refuses to start.
When i checked the Execution Report/page I noticed all my debugging sessions are still running. I tried to terminate them by selecting the 3-dots menu on the right and the Terminate command (for every single process).
Apparently the process/execution was terminated, I even received a confirmation:
But, as I refresh the page, all the executions are still up and running.
I posted an issue on the Google IssueTracker, but so far no answer. Other people have posted the same issue, but so far nobody has received an answer from Google.
https://issuetracker.google.com/issues/177450621
P.S. I'm not using triggers.
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.
To start with, I blamed the slow startup on this problem:
VS2010 and IE10 Attaching the Script debugger to process iexplore.exe failed
But after I fixed that, it still takes a really long time to start up a new debugging session... long enough to make you want to skip debugging.. that's not acceptable.
It's so long I feel like something is timing out before it actually starts IE and brings up the page.
Does anyone have any idea why and how to fix it?
It happening in vs2010 and vs2012..
Thanks,
Eric-
I often have this problem, usually after a couple of times of debugging, it turns to very slow to start up again.
What I do is to open task manager and kill the alive Webdev.Webserver40.EXE process which is not supposed to be there after you stop a debug.
I've had several times where I was writing a program using Visual Studio and something, somewhere along the line breaks. Naturally, my first thought is to set a breakpoint early on in the program and then step through the code slowly, line by line until I reach the error.
But often times I find that everything works correctly when slowly stepping through code in the debugger. However, when I just try to run the program without breakpoints something goes wrong.
Why does this happen? Is stepping through the code line by line actually different from just running the program in dubug mode?
(I'm not talking about debug vs release, i'm talking about debug vs line-by-line debugging)
One reason could be that you have timing issues between multiple executing threads that occur differently when the program runs "at full speed" and when you pause a thread in a debugger.
It could be due to a some thread unsafe operations that seem to happen correctly when stepping through the code but not at run time. Compiler optimizations are ruled out because you are sure that you are running a debug build.
Running inside the debugger materially alters the runtime options for eg. heap operations so that errors can be detected and surfaced to the user.
See here.
When a process is run under any debugger, certain heap debug options
are automatically enabled for all heaps in the process.
This is not for sure your issue, but a likely candidate.
So in a C# .NET v4 project in VS2010, I've got a debugging issue. Frequently, if not most of the time, the debugger freezes when you try to use it - typically on exceptions, it's usually OK if you try to manually break.
The only way I've discovered to fix this is to kill the debugged program ([projectname].vshost.exe), which unlocks the IDE and executes all the mouse presses and things that happened in its absence.
The main Windows GUI is not affected. There is minimal CPU load. Waiting does nothing. The output window (full of "Loaded xxx, symbols loaded") is uneventful. I've read about symbol servers deadlocks, or deadlocks in the GUI, but neither of those are the issue here (the symbol servers are disabled).
Anyone have any ideas? This is giving me a big problem, because I can't effectively debug the program.
Unfortunately, this could be any number of things.
Most often, I've had this type of thing happen when the program is caught in an infinite loop... but since yours is breaking on exceptions, maybe you could add some exception handling?
Never did figure this out. Oh well. Limped by with task manager open all summer, but made it through OK.