设置为开发人员模式时，Flask应用程序无法在cygwin上运行

问题描述

尝试使用以下命令在后台运行我的python flask应用程序后，立即发生了此问题:

$ python app.py&

此操作立即失败.之后，以后再尝试运行该应用程序(我之前所做的都没有问题)，最终会出现此错误:

  $ python app.py在http://127.0.0.1:8050/上运行调试器PIN:962-843-370*服务Flask应用应用"(延迟加载)*环境:发展*调试模式:打开2 [main] python3.6m 37104 child_info_fork :: abort:无法将_lbfgsb.cpython-36m-x86_64-cygwin.dll重映射到与父目录相同的地址(0x48E0000)-尝试运行rebaseall追溯(最近一次通话):< module>中的文件"app.py"，第644行app.run_server(debug = util.DEBUG)在run_server中的第1293行中，文件"/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/dash/dash.py"** flask_run_options)运行中的文件"/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/flask/app.py"，第943行run_simple(主机，端口，自我，**选项)文件"/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/serving.py"，第812行，在run_simple中reloader_type)在run_with_reloader中的第275行，文件"/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/_reloader.py"sys.exit(reloader.restart_with_reloader())文件"/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/_reloader.py"，行132，在restart_with_reloader中close_fds = False)通话中的文件"/usr/lib/python3.6/subprocess.py"，第267行用Popen(* popenargs，** kwargs)作为p:__init__中的文件"/usr/lib/python3.6/subprocess.py"，第709行restore_signals，start_new_session)_execute_child中的文件"/usr/lib/python3.6/subprocess.py"，第1275行restore_signals，start_new_session，preexec_fn)BlockingIOError:[Errno 11]资源暂时不可用 

该错误似乎源于在开发人员模式下运行，因为当我使用 app.run_server(debug = False)运行时(顺便说一句， util.DEBUG 设置为 True (在我的本地环境中)，该应用程序可以正常运行，但是然后我就无法进行热重载了，这对我来说很重要.

我已经按照这篇文章

为什么常规的 rebase ( rebaseall )无法解决问题?

• Cygwin 软件包具有安装后脚本，该脚本在其 .dll s

  上调用 rebase .

• rebase 在标准库路径(/lib ，/usr/lib ，...).可以根据 /usr/share/doc/Cygwin/_autorebase.README

  进行调整:

  由于可能包含 .dll s

  的软件包，

  Python 需要进行这样的调整

• pip 之类的软件包不具有安装后脚本(该脚本会重新构建其 .dll s)

• VEnv 在用户的主路径中，而在标准库路径中不是(因此，即使 rebaseall 也会忽略它们)

请注意，所有重新基于基础的 .dll 都存储在 DB 中:/etc/rebase.db(.${ARCH}).

为了使 .dll 被 rebase 工具拾取，需要对它们进行广告.这可以通过两种方式完成:

• 在其中一个自定义位置中指定它们，因此在下一次完全重新配置时，它们将不再被忽略(只需添加 VEnv 目录以及其他(如果有的话)):

• 手动重新构建 .dll s

他们两个都为我工作，但是我仅以2 变体为例(因为它更简单).该过程包括2个步骤:

• 创建所有需要重新建立基础的 .dll 的列表

• 执行变基

  • 所有 Cygwin 进程都必须关闭(包括服务:例如 sshd )
  • 我从 dash.exe 启动了命令(直接从 Cygwin bin dir从 Win 启动)，，而不是 Mintty (请注意提示)

更新的 Dependency Walker 窗口(检查其 Preferred Base ，并将其与上一张图像进行比较):

还有 rebase DB 查询"(现在从 Mintty 返回):

更重要的是，运行代码:

如所见，它能够多次分叉(它只是停止了，因为我按下了).

This problem occurred immediately after attempting to run my python flask app in the background using:

$python app.py &

This immediately failed. Afterwards, any future attempts to run the app, which I have done before with no problem, ending up providing this error:

 $ python app.py
Running on http://127.0.0.1:8050/
Debugger PIN: 962-843-370
 * Serving Flask app "app" (lazy loading)
 * Environment: development
 * Debug mode: on
      2 [main] python3.6m 37104 child_info_fork::abort: unable to remap _lbfgsb.cpython-36m-x86_64-cygwin.dll to same address as parent (0x48E0000) - try running rebaseall
Traceback (most recent call last):
  File "app.py", line 644, in <module>
    app.run_server(debug=util.DEBUG)
  File "/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/dash/dash.py", line 1293, in run_server
    **flask_run_options)
  File "/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/flask/app.py", line 943, in run
    run_simple(host, port, self, **options)
  File "/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/serving.py", line 812, in run_simple
    reloader_type)
  File "/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/_reloader.py", line 275, in run_with_reloader
    sys.exit(reloader.restart_with_reloader())
  File "/cygdrive/c/Users/mkupfer/Desktop/my_documents/01_Visualizations/eurostat/venv/lib/python3.6/site-packages/werkzeug/_reloader.py", line 132, in restart_with_reloader
    close_fds=False)
  File "/usr/lib/python3.6/subprocess.py", line 267, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.6/subprocess.py", line 1275, in _execute_child
    restore_signals, start_new_session, preexec_fn)
BlockingIOError: [Errno 11] Resource temporarily unavailable

The error seems to stem from running in developer mode since when I run with app.run_server(debug=False) (btw, util.DEBUG is set to True in my local environment), the app works fine, but then I don’t get hot reloading which is important for me.

I’ve tried rebasing cygwin as per this post https://superuser.com/a/194537/276726, but this didn’t fix anything.

I've also tried creating a special rebase file following the steps in this post, but that didn't help either.

The app works in development mode from my windows command line, so that is my temporary fix for now, but I would love to get my Cygwin setup running properly again.

Thanks for the help!

解决方案

You're running into a quite common problem in the Cygwin world. There are many URLs mentioning (dealing with) it, but I'm going to list the ones that I came across:

1. [SO]: Cygwin error: "-bash: fork: retry: Resource temporarily unavailable"
2. [SO]: Cygwin issue - unable to remap; same address as parent
3. [SuperUser]: Cygwin fatal error unable to remap.. What does it mean?
4. [WordPress]: Cygwin and Rails – unable to remap to same address as parent; died waiting for dll loading, errno 11
5. [SO]: Cygwin error: "child_info_fork::abort: Loaded to different address:"

The "behind the scenes magic" is very well explained in [Cygwin]: Problems with process creation (emphases are mine):

A troubleshooter is attempted in [Cygwin.FAQ]: 4.45. How do I fix fork() failures? (emphases still mine). With the risk of spamming the answer, I'm going to paste it here:

In order to reproduce the problem, I used:

• Cygwin 32:
  • The chance of running into the issue is much higher
  • It's not my main Cygwin env
• Python 3.6.4 + VEnv
  • Located at /home/cfati/Work/Dev/VEnvs/py_032_03.06.04_test0

I tried reproducing you exact behavior (with _lbfgsb*.dll), but pip -v install scipy failed to build it.
Since [GitHub.SciPy]: Installing SciPy on Windows describes a quite complex process, and I'd have no guarantee that at the end I'd be able to reproduce the problem, I tried with numpy's .dlls (numpy was successfully installed as a scipy dependency), but I wasn't able to (as a side effect, import numpy loads a bunch of .dlls), but calling fork (via subprocess.Popen) didn't fail.
Then I decided to take matter into my own hands, and create a small program that loads some .dlls, then forks itself (again, via subprocess.Popen), to make the problem as reproducible as possible.

dll.c:

#include <stdio.h>

#if defined(_WIN32)
#  define DLL_EXPORT __declspec(dllexport)
#else
#  define DLL_EXPORT
#endif


DLL_EXPORT int test() {
    printf("[%s] (%d) - [%s]\n", __FILE__, __LINE__, __FUNCTION__);
}

code.py:

#!/usr/bin/env python3

import sys
import os
import subprocess
import time
import select
import random
import ctypes


DLLS = [os.path.join(os.path.dirname(__file__), "dll{:d}.dll".format(item)) for item in range(2)]


def main():
    random.seed(os.getpid())
    random.shuffle(DLLS)
    if len(sys.argv) == 1:
        print("Python {:s} on {:s}\n".format(sys.version.replace("\n", ""), sys.platform))
        print("Process 0x{:08X}".format(os.getpid()))
        for dll in DLLS:
            ctypes.cdll.LoadLibrary(dll)
        idx = 0
        while sys.stdin not in select.select([sys.stdin], [], [], 1)[0]:
            p = subprocess.Popen([sys.executable] + sys.argv + [str(idx)])
            #p.communicate()
            time.sleep(1)
            idx += 1
        
    else:
        sleep_time = 3
        print("Process 0x{:08X} (inner) will end in {:d} seconds".format(os.getpid(), sleep_time))
        time.sleep(sleep_time)


if __name__ == "__main__":
    main()

Notes:

• The scenario is a bit different, instead of a Python Extension Module, I have a regular (dummy) .dll, which I attempt loading it via [Python.Docs]: ctypes - A foreign function library for Python. This should make no difference, as no matter how Python sees it (as an module, or as an external .dll) it will still have to load it into the process (the same way)
• The scenario is:
  • I load 2 such .dlls (actually it's the same .dll copied under a different name, so they both have the same Preferred Base Address), so the 1 .dll will probably be loaded at that address, while the next .dll will be loaded at a different one
  • Then I fork the process, and in the child, based on a random factor, I switch the .dll loading order
  • When the 2 .dll will be loaded at the preferred base, there'll be an inconsistency with the parent process, yielding the error
• At the beginning everything was in my cwd, then (to be closer to your problem), I created a Python package with the files. Note that I didn't do it the proper way (installation via a setup.py file), but manually copying everything

So, the error is quite reproducible. I'd also like to add here the .dll details (Dependency Walker):

Why doesn't a regular rebase (rebaseall) solve the problem?

• Cygwin packages have a post install script that calls rebase on their .dlls

• rebase searches in standard library paths (/lib, /usr/lib, ...). That can be adjusted, according to /usr/share/doc/Cygwin/_autorebase.README:

  Python requires such an adjustment, due to packages that may contain .dlls

• pip like packages do not have a post install script (that would rebase their .dlls)

• The VEnv is in the user's home path which is not in the standard library paths (so, even a rebaseall will ignore them)

Note that all the rebased .dlls are stored in a DB: /etc/rebase.db(.${ARCH}).

In order the .dlls to be picked up by rebase tools, they need to be advertised. That can be done in 2 ways:

• Specify them in one of the custom locations, so at the next full rebase they will no longer be ignored (simply add the VEnv dir, and others if any):

• Manually rebase the .dlls

Both of them worked for me, but I'm going to exemplify on the 2 variant only (as it's simpler). The process consists of 2 steps:

• Create a list of all .dlls that need to be rebased

• Perform the rebase

  • All the Cygwin processes must be closed (including services: e.g. sshd)
  • I launched the command from dash.exe (started directly from Win, from Cygwin bin dir), and not from Mintty (notice the prompt)

The updated Dependency Walker window (check its Preferred Base, and compare it to the one in the previous image):

And also the rebase DB "query" (now back from Mintty):

What's more important, running the code:

As seen it is able to fork itself multiple times (it only stopped because I pressed ).

这篇关于设置为开发人员模式时，Flask应用程序无法在cygwin上运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！