【问题标题】:Flask/Werkzeug with Python 3.7 on Cygwin: BlockingIOError: [Errno 11] Resource temporarily unavailableCygwin 上使用 Python 3.7 的 Flask/Werkzeug:BlockingIOError:[Errno 11] 资源暂时不可用
【发布时间】:2020-09-16 09:27:09
【问题描述】:

Cygwin 上的 Python 3.7 似乎与 Werkzeug 存在一些问题。我有一个复杂的 Flask 应用程序,并决定将我的 virtualenv 升级到 3.7,但突然间我看到了这个警告

0 [main] python3.7 1642 child_info_fork::abort: 需要地址空间 通过'bit_generator.cpython-37m-x86_64-cygwin.dll'(0x600000)已经 占用

或者它只是因为 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

尚不清楚哪个部分是罪魁祸首。如果我尝试清空我的 init.py,它似乎有一些导入链的问题(导入一个导入另一个文件的文件)。我认为罪魁祸首之一是子流程的导入,但事实并非如此。

我可以做些什么来获得更多输出,以便提供更多信息来解决这个问题?我这里不能真正复制整个代码,看起来一个简单的项目没有这个问题。

【问题讨论】:

  • (0x600000) 地址非常低。可能是 BLODA 干扰cygwin.com/faq.html#faq.using.bloda
  • @matzeri 好的,我想我应该暂时切换回 python3.6。卸载东西是没有问题的,特别是因为我在那个有趣的命名列表上安装的唯一东西是核心东西(window defer,citrix ..)。为什么低地址让你认为这是问题所在?

标签: flask cygwin werkzeug


【解决方案1】:

在正确的 Cygwin 安装中,共享库总是在比你的 fork 失败案例更高的地址上运行。

要查看预期范围,您可以查看基地址数据库。
在我当前的系统上:

$ 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

因此,或者您的数据库已损坏并且未正确执行变基,或者 BLODA 正在干扰正确加载您的 dll。

【讨论】:

  • 谢谢。我不能再复制它了,因为我不得不继续,因此使用了 python3.6。我通过重新创建一个 venv 再次尝试,但在复制它时没有运气。希望这会帮助其他人看到这一点。
猜你喜欢
  • 2012-11-13
  • 1970-01-01
  • 2011-08-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多