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

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

笔记：

>情况有所不同,我有一个常规的(虚拟).dll,而不是Python扩展模块,我尝试通过[Python 3.Docs]: ctypes – A foreign function library for Python加载它.无论Python如何看待它(作为一个模块),这都没有区别.,或作为外部.dll),仍然必须将其加载到进程中(以相同的方式)
>场景是：

>我加载了2个这样的.dll(实际上是相同的.dll以不同的名称复制,因此它们都具有相同的首选基址),因此第一个.dll可能会加载到该地址,而下一个.dll将装在另一个
>然后我分叉该过程,并在子级中基于随机因素切换.dll加载顺序
>当第二个.dll将在首选库中加载时,将与父进程不一致,从而产生错误

>最初,所有内容都在我的cwd中,然后(为了更贴近您的问题),我用文件创建了一个Python包.请注意,我没有采取正确的方式(通过setup.py文件安装),而是手动复制了所有内容

06002

因此,该错误是非常可重现的.我还要在此添加.dll详细信息(Dependency Walker)：

定期重新设置基准(rebaseall)为什么不能解决问题？

> Cygwin软件包具有一个安装后脚本,该脚本在其.dll上调用重新设置
>在标准库路径(/ lib,/usr/lib,…)中重新搜索.可以根据/usr/share/doc/Cygwin/_autorebase.README进行调整：

Packages can make the potential locations of such dynamic objects
known by dropping a file (named after the package) in
/var/lib/rebase/dynpath.d/. If any dynamic objects are installed by
users,these locations should be advertised in /var/lib/rebase/user.d/
(the file name should be identical to the user name if there are
multiple users on this system)

由于包可能包含.dll,因此Python需要进行此类调整.
>点子一样的软件包没有安装后脚本(该脚本会重新设置其.dll)
> VEnv位于用户的主路径中,而不位于标准库路径中(因此,即使是rebaseall也会忽略它们)

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

06003

为了使.dll被变基工具拾取,需要对它们进行公告.这可以通过两种方式完成：

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

06004

>手动重新建立.dll的基准

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

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

06005

>执行基准

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

06006

更新后的Dependency Walker窗口(检查其“首选基础”,并将其与上一张图像进行比较)：

以及重新设置数据库的“查询”(现在从Mintty返回)：

06007

更重要的是,运行代码：

06008

如图所示,它能够多次分叉(它只是因为按Enter才停止).