设置为开发人员模式时,Cygwin不再支持Flask应用

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

$python app.py&

这立即失败了.之后,以后我再也没有问题地尝试运行该应用程序,最终都会出现此错误：

 $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

该错误似乎源于在开发人员模式下运行,因为当我使用app.run_server(debug = False)运行时(顺便说一句,在我的本地环境中util.DEBUG设置为True),该应用程序运行良好,但随后我没有进行热装,这对我很重要.

我已尝试根据此帖子https://superuser.com/a/194537/276726重新设置cygwin,但这并不能解决任何问题.

我也尝试按照this post中的步骤创建一个特殊的变基文件,但这也无济于事.

该应用程序可从Windows命令行以开发模式运行,因此这是我目前的临时修复程序,但我希望我的Cygwin设置能够再次正常运行.

谢谢您的帮助！

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

[Cygwin]: Problems with process creation中很好地解释了“幕后魔术”(重点是我的)：

The semantics of fork require that a forked child process have exactly the same address space layout as its parent. However,Windows provides no native support for cloning address space between processes and several features actively undermine a reliable fork implementation. Three issues are especially prevalent:

• DLL base address collisions. Unlike *nix shared libraries,which use “position-independent code”,Windows shared libraries assume a fixed base address. Whenever the hard-wired address ranges of two DLLs collide (which occurs quite often),the Windows loader must “rebase” one of them to a different address. However,it may not resolve collisions consistently,and may rebase a different dll and/or move it to a different address every time. Cygwin can usually compensate for this effect when it involves libraries opened dynamically,but collisions among statically-linked dlls (dependencies known at compile time) are resolved before cygwin1.dll initializes and cannot be fixed afterward. This problem can only be solved by removing the base address conflicts which cause the problem,usually using the rebaseall tool.
• Address space layout randomization (ASLR). Starting with Vista,Windows implements ASLR,which means that thread stacks,heap,memory-mapped files,and statically-linked dlls are placed at different (random) locations in each process. This behaviour interferes with a proper fork,and if an unmovable object (process heap or system dll) ends up at the wrong location,Cygwin can do nothing to compensate (though it will retry a few times automatically).

尝试在[Cygwin.FAQ]: 4.45. How do I fix fork() failures?中进行故障排除(重点仍然存在).冒着散布答案的风险,我将其粘贴在这里：

Unfortunately,Windows does not use the fork/exec model of process creation found in UNIX-like OSes,so it is difficult for Cygwin to implement a reliable and correct fork(),which can lead to error messages such as:

• unable to remap somedll to same address as parent
• couldn’t allocate heap
• died waiting for dll loading
• child -1 – died waiting for longjmp before initialization
• STATUS_ACCESS_VIOLATION
• resource temporarily unavailable

Potential solutions for the above errors:

• Restart whatever process is trying (and failing) to use fork(). Sometimes Windows sets up a process environment that is even more hostile to fork() than usual.
• Ensure that you have eliminated (not just disabled) all software on the 07007.
• Switch from 32-bit Cygwin to 64-bit Cygwin,if your OS and CPU support that. With the bigger address space fork() is less likely to fail.

• Try setting the environment variable CYGWIN to “detect_bloda”,which enables some extra debugging,which may indicate what other software is causing the problem.

  See 07008 for more information.

• Force a full rebase: Run rebase-trigger fullrebase,exit all Cygwin programs and run Cygwin setup.

  By default,Cygwin’s setup program automatically performs an incremental rebase of newly installed files. Forcing a full rebase causes the rebase map to be cleared before doing the rebase.

  See /usr/share/doc/rebase/README and /usr/share/doc/Cygwin/_autorebase.README for more details.

  Please note that installing new packages or updating existing ones undoes the effects of rebase and often causes fork() failures to reappear.

See the 07009 section of the User’s Guide for the technical reasons it is so difficult to make fork() work reliably.

为了重现该问题,我使用了：

> Cygwin 32：

>遇到问题的机会要高得多
>这不是我的主要Cygwin环境

> Python 3.6.4 VEnv

>位于/home/cfati/Work/Dev/VEnvs/py_032_03.06.04_test0

我尝试重现您的确切行为(使用_lbfgsb * .dll),但是pip -v install scipy无法构建它.由于[SciPy]: Installing SciPy on Windows描述了一个相当复杂的过程,并且我无法保证最后我能够重现该问题,因此我尝试使用numpy的.dll(numpy已成功安装为scipy依赖项),但我没有这样做.能够(作为副作用,import numpy加载了一堆.dll),但是(通过subprocess.Popen)调用fork并没有失败.然后,我决定亲自处理这个问题,并创建一个加载一些.dll的小程序,然后分叉自身(同样,通过subprocess.Popen),以使问题尽可能重现.

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()

笔记：

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!