MCVE:
import threading
threading.Thread(target=input, daemon=True).start()
If you run the above as a script in PyCharm with the default run configuration (without entering any input), you get the following fatal error when the program terminates:
Fatal Python error: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=00000200EF89E1C0)
Thread 0x0000459c (most recent call first):
File "C:\Program Files\Python38\lib\threading.py", line 870 in run
File "C:\Program Files\Python38\lib\threading.py", line 932 in _bootstrap_inner
File "C:\Program Files\Python38\lib\threading.py", line 890 in _bootstrap
Current thread 0x00001b78 (most recent call first):
<no Python frame>
But if you run this from the terminal with python script.py or check the "Emulate terminal in output console" in PyCharm for this run configuration, no such error occurs.
As far as I understand, the error happens because when input is called, it suspends the thread indeterminately until input returns (and there's no way of interrupting this), blocking stdin during this time, so when the main thread terminates, since the other thread is a daemon, Python starts finalization, and when it tries to reacquire the lock for stdin, it can't because it is still locked by the input call.
But the question is, why does it make a difference whether it is run in PyCharm's output console vs a terminal/terminal emulator? Does the terminal make Python not try to reacquire the lock? Or does the error still occur but it gets silenced for some reason? Or what?
If case this helps, in CPython, this error is raised in the _enter_buffered_busy function in bufferedio.c.
UPDATE: I've filed a ticket on PyCharm's issue tracker.
Related
A very large application I am working has a segfault when I shut it down. If I use faulthandler, it says there is an access violation in atexit
Current thread 0x00000a8c (most recent call first):
File "C:\Python27\lib\atexit.py", line 24 in _run_exitfuncs
Windows exception: access violation
Current thread 0x00000a8c (most recent call first):
File "C:\Python27\lib\atexit.py", line 24 in _run_exitfuncs
Segmentation fault
That really doesn't tell me much. When I debug through the code, it goes all the way through main and out. The debugger won't step anymore after that, even though the program isn't all the way done yet. If I let it continue, it just does the segfault and doesn't show me anything.
I imagine it is some library we are using, but how to identify it?
Very simple minimal example:
if __name__ == '__main__':
print("Still ok")
raise Exception("Dummy exception")
print("End of Program")
I get this output when running it in the PyCharm 2019.2 debugger with Python 3.6:
/usr/bin/python3.6 /home/[...]/pycharm-community-2019.2/helpers/pydev/pydevd.py --multiproc --qt-support=auto --client 127.0.0.1 --port 46850 --file /home/[...]/test_traceback.py
pydev debugger: process 18394 is connecting
Connected to pydev debugger (build 192.5728.105)
Still ok
At this point the debugger breaks the execution flow but no Traceback and Exception message is shown in the Debugger console. If I run the same in PyCharm 2018.1 it does show these right when the breakpoint is hit.
When I hit , I get the desired output, but then I can't run code in the debugging context anymore because the process ends:
Traceback (most recent call last):
File "/home/[...]/pycharm-community-2019.2/helpers/pydev/pydevd.py", line 2060, in <module>
main()
File "/home/[...]/pycharm-community-2019.2/helpers/pydev/pydevd.py", line 2054, in main
globals = debugger.run(setup['file'], None, None, is_module)
File "/home/[...]/pycharm-community-2019.2/helpers/pydev/pydevd.py", line 1405, in run
return self._exec(is_module, entry_point_fn, module_name, file, globals, locals)
File "/home/[...]/pycharm-community-2019.2/helpers/pydev/pydevd.py", line 1412, in _exec
pydev_imports.execfile(file, globals, locals) # execute the script
File "/home/[...]/pycharm-community-2019.2/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "/home/[...]/test_traceback.py", line 4, in <module>
raise Exception("Dummy exception")
Exception: Dummy exception
Process finished with exit code 1
My Breakpoint configuration:
It works on PyCharm (Community) 2019.1.4:
Seems like you ran into a (regression) bug:
[JetBrains.YouTrack]: No Traceback in Debugger's Console
[JetBrains.YouTrack]: No stack trace is printed to the console when debugger breaks on exception
which affects v2019.2.1, and is scheduled to be fixed in v2019.2.3.
To get past this issue, you'll have to either:
Wait for v2019.2.3 (or any other that has the fix) to be released, and switch to that (might want to (periodically) check [JetBrains.Blog]: Release Announcements)
Revert to a (previous) version which is not affected by the bug (as I already mentioned: 2019.1.4)
As a note: when running into this kinds of situations, in the (unlikely) case that the problem is not yet known, one could take matters into their own hands, do some debugging, and fix the problem (maybe submit a patch with the fix to JetBrains). Check [SO]: Run / Debug a Django application's UnitTests from the mouse right click context menu in PyCharm Community Edition? for an example.
Update #0
Installed (on 20190930) latest patch (v2019.2.3), and the traceback is present in PyCharm's console (so, the bug is fixed).
did you check your whitespaces at start of each executable line? one time it occured to me was fixed after just correcting the whitespaces.
I'd like my program to automatically exit if it detects an error when loading a file and parsing it (even when called from an interactive mode with -i). I've tried variations of exit() and sys.exit(), but nothing seems to be working. Instead of exiting the interactive session I get a stack trace. For example, if I have the file test.py that is the following:
import sys
sys.exit(0)
when I run python3 -i test.py I get the following result:
Traceback (most recent call last):
File "test.py", line 2, in <module>
sys.exit()
SystemExit
>>>
and the session continues on, until I exit myself (using those exact lines subsequently work, just not when they're called from the script). What am I missing?
Try calling os._exit() to exit directly, without throwing an exception
import os
os._exit(1)
Note that this will bypass all of the python shutdown logic.
Hope it helps.
I am running a script inside Spyder that utilizes the multithreading library and the IPython console freezes with the output below. However, running the script using Windows command prompt via 'python quickstart11.py' works fine and generates the proper output.
runfile('C:/Python35/User/backtrader-master/docs/quickstart/quickstart11.py', wdir='C:/Python35/User/backtrader-master/docs/quickstart')
Exception in thread Thread-8:
Traceback (most recent call last):
File "C:\Anaconda3\lib\threading.py", line 914, in _bootstrap_inner
self.run()
File "C:\Anaconda3\lib\threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "C:\Anaconda3\lib\multiprocessing\pool.py", line 429, in _handle_results
task = get()
File "C:\Anaconda3\lib\multiprocessing\connection.py", line 251, in recv
return ForkingPickler.loads(buf.getbuffer())
AttributeError: Can't get attribute 'TestStrategy' on <module '__main__' (<_frozen_importlib_external.SourceFileLoader object at 0x000002727C461438>)>
I've tried adding freeze_support() according to Python doc, which should alleviate the problem, but it still freezes. What is going on?
Windows 10 64bit, Anaconda Python 35 64bit installer.
The problem is in Spyder. The kernel is running in interpreted mode and the addition of "freeze_support" doesn't happend before other things even if that's the intention, because the kernel is already running.
See here: https://github.com/mementum/backtrader/issues/118
I get this error with multiprocessing when looping a simple range.
Process PoolWorker-37:
Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/process.py", line 249, in _bootstrap
sys.stdin.close()
AttributeError: StdIn instance has no attribute 'close'
The code
pool = multiprocessing.Pool(processes=3)
pool.map(get_info, range(20000,20010), 1)
pool.close()
pool.join()
Update
the first issue was by eclipse altering the environment, but now I get this error
PicklingError: Can't pickle <type 'cStringIO.StringO'>: attribute lookup cStringIO.StringO failed
This error is thrown if you are running in PyCharm console. I used the system console and all ran ok.
In PyCharm 4.5 the solution for me was to remove "Show command line afterwards" checkbox in server Run/Debug configuration for python file (which is not even documented in PyCharm manual)