セグメンテーション違反、OSX上のマルチプロセッシングとnumpyののlapack_liteを使用してOSX 10.7.3上で私のために

Question

次のテストコードセグメンテーション違反をLinuxにはない、ではなく、他のマシン：

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) 

segfaultyものの一つのための出力例：

$ 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を呼び出すと、それでもなおsegfaultsが発生します。私が別の小さな配列で呼び出す場合、またはf(large_array)を呼び出してf(small_array)を別のプロセスに渡すと、正常に動作します。実際には同じ機能を持つ必要はありません。 np.inv(large_array)に続いてnp.linalg.slogdet(different_large_array)にも転送されます。

np.linalgのすべてのコメントは、クラッシュする原因となります。 np.dot(self.a, self.a.T).sum()とscipy.linalg.exp3mは問題ありません。私が知る限り、違いは前者がnumpyのlapack_liteを使用し、後者が使用しないことです。

---

これは

• のpython 2.6.7、1.5.1 numpyの
• のpython 2.7.1、1.5.1 numpyの、scipyのダウンロード0.10.0
• と私のデスクトップ上に私のために起こりますpython 3.2.2、numpy 1.6.1、scipy 0.10.1

私はデフォルトシステムがインストールされていると思います。ソースtarballから手動で3.2バージョンをインストールしました。私は同様のセットアップで別のMacで同じ動作を取得

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

：これらnumpysのすべては、フレームワークを加速するシステムにリンクされています。

しかし、他のマシン上f仕事のためのすべてのオプションは、Python 2.6.1および4を加速するためにリンクされnumpyの1.2.1とそれがないこと以外はVECLIB 268（と

• OSX 10.6.8を実行していますPythonの3.2.2と
• ）scipyのダウンロード又はslogdetのDebian 6、numpyの1.6.1、およびシステムATLASのPython 2.7.1と
• のUbuntu 11.04に連結scipyのダウンロード0.10.1、numpyの1.5.1とscipyのダウンロード0.8を有します。システムにリンクされた0 ATLAS

---

ここで何か問題がありますか？おそらく何が原因でしょうか？私はpickleとunpickledになるnumpy配列の関数を実行すると、後で別のプロセスでsegfaultを引き起こす可能性があります。

---

アップデート：私はコア・ダンプを行うとき、バックトレースがdispatch_group_async_f内にある、グランドセントラルディスパッチインターフェイス。おそらく、これはnumpy/GCDとマルチプロセッシングの間の相互作用のバグです。私はこれをa numpy bugと報告していますが、誰かが回避策やバグの解決方法についてアイデアを持っていれば、非常に感謝しています。 :)

Answer 1

OSX just doesn't support using BLAS calls on both sides of a forkでデフォルトで使用されているAccelerateフレームワークが判明しました。別のBLASにリンクする以外の方法はありません。修正することに興味があるようなものではありません。