Python debugger not working while normal run does
Answered
The python debugger in Pycharm (I've the latest version) is not working for any Python file (so it's not my project or anything). While running the file normally in Pycharm works perfectly.
Also the window saying "Python has stopped working" keeps popping up even though I'm not running anything.
I updated my Java version following some advice on a post but it doesn't help.
Here's the log from idea.log file:
2018-08-07 11:40:41,348 [ 257607] ERROR - python.debugger.PyDebugProcess - socket closed
java.net.SocketException: socket closed
at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method)
at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:199)
at java.net.ServerSocket.implAccept(ServerSocket.java:545)
at java.net.ServerSocket.accept(ServerSocket.java:513)
at com.jetbrains.python.debugger.pydev.transport.ServerModeDebuggerTransport.waitForConnect(ServerModeDebuggerTransport.java:39)
at com.jetbrains.python.debugger.pydev.RemoteDebugger.waitForConnect(RemoteDebugger.java:89)
at com.jetbrains.python.debugger.pydev.MultiProcessDebugger.waitForConnect(MultiProcessDebugger.java:80)
at com.jetbrains.python.debugger.PyDebugProcess$5.run(PyDebugProcess.java:295)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:736)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(CoreProgressManager.java:157)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:580)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:525)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:85)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:144)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:395)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:310)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - PyCharm 2018.2 Build #PC-182.3684.100
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - JDK: 1.8.0_152-release
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - VM: OpenJDK 64-Bit Server VM
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - Vendor: JetBrains s.r.o
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - OS: Windows 10
2018-08-07 11:40:41,349 [ 257608] ERROR - python.debugger.PyDebugProcess - Last Action: Debug
2018-08-07 11:40:46,115 [ 262374] INFO - .skeletons.PySkeletonRefresher - Skeleton for PyQt5.QtBluetooth
2018-08-07 11:40:48,807 [ 265066] INFO - .skeletons.PySkeletonRefresher - Skeleton for PyQt5.QtCore
2018-08-07 11:40:50,179 [ 266438] INFO - .skeletons.PySkeletonRefresher - Skeleton for PyQt5.QtDBus
Please sign in to leave a comment.
I have the same problem, just new a project in RHEL7, pycharm will fail to debug Web3, but run in terminal venv seem to work. Looks pycharm debugger can't resolve environment the same as the terminal. it is a bug for sure.
I solved the problem by copying the whole project directory, opening that -- now debugging worked. I then renamed the copy to the old directory name, and debugging worked.
Other solutions, like creating a new virtual env, or deleting a Run Configuration and recreating that, did not work.
Pycharm 2019.3 on Macbook OSX10.1.5.7
My version of debugger not working is:
```
Connected to pydev debugger (build 203.7717.81)
Process finished with exit code -1073741819 (0xC0000005)
```
What are the possible causes? I tried the fixes above, but no luck. Has there been a bugfix in any version since this thread was started? Alse refactoring is very hit and miss for the project with this issue. Are there any more names like ''code.py" I should avoid
I am on the latest (paid) version (2020.3.5), Python 3.7, using PySide2. This is becoming a real time sink (fixing it and debugging without debugger).
Hi all,
I don't know if this is gonna be helpful, I am a beginner but when I start the debugger and press the button Step into F7, it brings up the error. However, this doesn't happen with the button next to it which is Step into my code. I hope this will be helpful.
Here is a screenshot of the issue and the button that I use.
Hi Hsavova0, what do you mean by "it brings up the error"? Looks like it just stepped into the library code, which is expected. Please feel free to create a ticket in PyCharm's bug tracker and provide an example.
For me tokenizer fails to detect encoding when it finds a line "serialization.Encoding.DER" - but that is a external library function call, I can not change that to not enclude word "encoding"
This file used to be debugged normally a year ago, now debugging is totally not working. What happened?
THIS WORKED !!
"I don't know if this will help anyone in the future but I experience the same issue. In my case I had a file named queue.py in my project.
Once I renamed that file the debugger started to work again."
But does anyone know *why* this works? I ran into it twice, normal runs are fine, debugger, I got:
ImportError: cannot import name 'Redis' from 'redis'
If I renamed a test directory from `redis` to `redis_test`, poof, works. Similar thing with a test directory called `datadog`, rename to `datadog_test`, and it works. This is very obscure. I wasn't even running tests in those directories. I just started renaming anything called "redis" and "datadog" to something else and figured out it was the test directory names causing the issue.
It happens because the debugger uses some of the standard Python libraries, and when it's trying to import, for example, string and you have a string.py module in your project root, it ends up importing the one from your project and hence breaks.
We have a ticket about that https://youtrack.jetbrains.com/issue/PY-23615/Dont-break-when-debugging-files-with-names-shadowing-standard-modules