segfault sử dụng lapack_lite NumPy với đa xử trên OSX, không linux

Question

Các segfaults mã kiểm tra sau đối với tôi trên OSX 10.7.3, nhưng không phải máy khác:

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) 

Ví dụ đầu ra cho một trong những người segfaulty:

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

calling with multiprocessing 
about to call 

calling with multiprocessing 
about to call 

với báo cáo sự cố "OSX" xuất hiện phàn nàn về một khoảng cách như KERN_INVALID_ADDRESS at 0x0000000000000108; here's a full one.

Nếu tôi chạy nó với n <= 32, nó chạy tốt; cho bất kỳ n >= 33, nó bị treo.

Nếu tôi nhận xét cuộc gọi f(a) được thực hiện trong quá trình ban đầu, cả hai cuộc gọi đến call_proc đều ổn. Nó vẫn segfaults nếu tôi gọi f trên một mảng lớn khác nhau; nếu tôi gọi nó trên một mảng nhỏ khác, hoặc nếu tôi gọi f(large_array) và sau đó vượt qua f(small_array) đến một quy trình khác, nó hoạt động tốt. Họ không thực sự cần phải có cùng chức năng; np.inv(large_array) theo sau bằng cách chuyển sang số np.linalg.slogdet(different_large_array) cũng là các segfaults.

Tất cả các nhận xét ra np.linalg mọi thứ trong f gây ra sự cố; np.dot(self.a, self.a.T).sum() và scipy.linalg.exp3m hoạt động tốt. Theo như tôi có thể nói, sự khác biệt là trước đây sử dụng lapack_lite của numpy và sau đó không.

---

Điều này xảy ra đối với tôi trên máy tính để bàn của tôi với

• 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

2.6 và 2.7 tôi nghĩ hệ thống mặc định sẽ được cài đặt; Tôi đã cài đặt phiên bản 3.2 theo cách thủ công từ kho dữ liệu nguồn. Tất cả các gói lưu trữ đó được liên kết với khung Tăng tốc hệ thống:

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

Tôi nhận được cùng một hành vi trên một máy Mac khác có cài đặt tương tự.

Nhưng tất cả các tùy chọn cho f làm việc trên các máy khác chạy

• OSX 10.6.8 với Python 2.6.1 và 1.2.1 NumPy liên quan đến Tăng tốc 4 và vecLib 268 (ngoại trừ việc nó không có scipy hoặc slogdet)
• Debian 6 với Python 3.2.2, gọn gàng 1.6.1 và scipy 0.10.1 được liên kết với hệ thống ATLAS
• Ubuntu 11.04 với Python 2.7.1, numpy 1.5.1 và scipy 0.8. 0 được liên kết với hệ thống ATLAS

---

Tôi có làm gì sai ở đây không? Điều gì có thể gây ra điều này? Tôi không thấy làm thế nào chạy một hàm trên một mảng numpy đó là nhận được ngâm và unpickled có thể có thể gây ra nó để segfault sau này trong một quá trình khác nhau.

---

Cập nhật: khi tôi làm một bãi chứa lõi, các vết lùi là bên trong dispatch_group_async_f, giao diện Grand Central Dispatch. Có lẽ đây là một lỗi trong các tương tác giữa numpy/GCD và đa xử lý. Tôi đã báo cáo điều này là a numpy bug, nhưng nếu có ai có bất kỳ ý tưởng nào về cách giải quyết hoặc, về vấn đề đó, cách giải quyết lỗi, nó sẽ được đánh giá cao. :)

Answer 1

Hóa ra khung gia tốc được sử dụng theo mặc định trên OSX just doesn't support using BLAS calls on both sides of a fork. Không có cách nào thực sự để đối phó với điều này ngoài việc liên kết với một BLAS khác, và nó không có vẻ giống như một cái gì đó mà họ quan tâm đến việc sửa chữa.