It seems that Python 3.7 on Cygwin has some issues with Werkzeug. I have a complex Flask application and decided to upgrade my virtualenv to 3.7 and suddenly I either see this warning
0 [main] python3.7 1642 child_info_fork::abort: address space needed by 'bit_generator.cpython-37m-x86_64-cygwin.dll' (0x600000) is already occupied
Or it plain just crash with a BlockingIOError.
Traceback (most recent call last):
File "run.py", line 5, in <module>
app.run(debug=True)
File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/flask/app.py", line 990, in run
run_simple(host, port, self, **options)
File "/cygdrive/c/maga/personale/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/serving.py", line 1050, in run_simple
run_with_reloader(inner, extra_files, reloader_interval, reloader_type)
File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/_reloader.py", line 339, in run_with_reloader
sys.exit(reloader.restart_with_reloader())
File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/_reloader.py", line 183, in restart_with_reloader
exit_code = subprocess.call(args, env=new_environ, close_fds=False)
File "/usr/lib/python3.7/subprocess.py", line 339, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.7/subprocess.py", line 1482, in _execute_child
restore_signals, start_new_session, preexec_fn)
BlockingIOError: [Errno 11] Resource temporarily unavailable
It is not clear which part is the culprit. If I try empty my init.py it seems it has problems with some import chains (import a file that import another file). I thought one of the culprit was the importing of subprocess, but it isn't.
Is there something I can do to get more output in order to give more information to solve this issue? I can't really copy the whole code here and it seems that a simple project doesn't have this issue.
In a proper Cygwin installation the shared libraries are always run at higher address than your fork failure case.
To see the expected range you can look at the base address database.
On my current system:
$ rebase -si | awk '{ print $3, $1}' |sort |head -n 5
0x0003ce2c0000 /usr/libexec/coreutils/libstdbuf.so
0x0003ce2d0000 /usr/lib/texinfo/XSParagraph.dll
0x0003ce2e0000 /usr/lib/texinfo/Parsetexi.dll
0x0003ce310000 /usr/lib/texinfo/MiscXS.dll
0x0003ce320000 /usr/lib/sasl2_3/cygscram-3.dll
$ rebase -si | awk '{ print $3, $1}' |sort -r |head -n 5
0x0003fffd0000 /usr/bin/cygEGL-1.dll
0x0003fffa0000 /usr/bin/cygEMF-1.dll
0x0003fff20000 /usr/bin/cygFLAC-8.dll
0x0003ffea0000 /usr/bin/cygGL-1.dll
0x0003ffe30000 /usr/bin/cygGLU-1.dll
so or your database is damaged and rebasing was not performed properly, or a BLODA is interfering in loading your dlls properly.