python - 在 osx 上使用 numpy 的 lapack_lite 进行多处理的段错误，而不是 linux

Question

以下测试代码在 OSX 10.7.3 上对我来说是段错误，但在其他机器上不是:

from __future__ import print_function

import numpy as np
import multiprocessing as mp
import scipy.linalg

def f(a):
    print("about to call")

    ### these all cause crashes
    sign, x = np.linalg.slogdet(a)
    #x = np.linalg.det(a)
    #x = np.linalg.inv(a).sum()

    ### these are all fine
    #x = scipy.linalg.expm3(a).sum()
    #x = np.dot(a, a.T).sum()

    print("result:", x)
    return x

def call_proc(a):
    print("\ncalling with multiprocessing")
    p = mp.Process(target=f, args=(a,))
    p.start()
    p.join()


if __name__ == '__main__':
    import sys
    n = int(sys.argv[1]) if len(sys.argv) > 1 else 50

    a = np.random.normal(0, 2, (n, n))
    f(a)

    call_proc(a)
    call_proc(a)

其中一个段错误的示例输出:

$ python2.7 test.py
about to call
result: -4.96797718087

calling with multiprocessing
about to call

calling with multiprocessing
about to call

弹出 OSX“问题报告”，提示像 KERN_INVALID_ADDRESS at 0x0000000000000108 这样的段错误; here's a full one .

如果我用 n <= 32 运行它，它运行良好；对于任何 n >= 33 ，它崩溃了。

如果我注释掉 f(a)调用在原始过程中完成，两次调用 call_proc没事。如果我调用 f 仍然会出现段错误在不同的大阵列上；如果我在不同的小阵列上调用它，或者如果我调用 f(large_array)然后通过f(small_array)对于不同的过程，它工作正常。它们实际上不需要具有相同的功能； np.inv(large_array)然后冒充np.linalg.slogdet(different_large_array)也有段错误。

所有注释掉的np.linalg东西在f导致崩溃； np.dot(self.a, self.a.T).sum()和 scipy.linalg.exp3m工作正常。据我所知，区别在于前者使用 numpy 的 lapack_lite 而后者不使用。

---

这发生在我的桌面上

• python 2.6.7，numpy 1.5.1
• python 2.7.1，numpy 1.5.1，scipy 0.10.0
• python 3.2.2、numpy 1.6.1、scipy 0.10.1

我认为 2.6 和 2.7 是默认系统安装；我从源压缩包中手动安装了 3.2 版本。所有这些 numpys 都链接到系统 Accelerate 框架:

$ otool -L `python3.2 -c 'from numpy.core import _dotblas; print(_dotblas.__file__)'`
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/numpy/core/_dotblas.so:
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

我在另一台具有类似设置的 Mac 上遇到相同的行为。

但是 f 的所有选项在其他机器上工作

• 带有 Python 2.6.1 和 numpy 1.2.1 的 OSX 10.6.8 链接到 Accelerate 4 和 vecLib 268(除了它没有 scipy 或 slogdet)
• Debian 6 与 Python 3.2.2、numpy 1.6.1 和 scipy 0.10.1 链接到系统 ATLAS
• Ubuntu 11.04 与 Python 2.7.1、numpy 1.5.1 和 scipy 0.8.0 链接到系统 ATLAS

---

我是不是做错了什么？可能是什么原因造成的？我看不出在经过 pickle 和 unpickled 的 numpy 数组上运行一个函数可能会导致它稍后在不同的进程中出现段错误。

---

更新:当我进行核心转储时，回溯在 dispatch_group_async_f 内, Grand Central Dispatch 界面。大概这是 numpy/GCD 和多处理之间交互的一个错误。我将其报告为 a numpy bug ，但如果有人对解决方法有任何想法，或者就此而言，如何解决错误，我们将不胜感激。 :)

Answer 1

事实证明，OSX 上默认使用的 Accelerate 框架 just doesn't support using BLAS calls on both sides of a fork .除了链接到不同的 BLAS 之外，没有真正的方法来处理这个问题，而且他们似乎没有兴趣解决这个问题。