segfault использует lapack_lite от numpy с многопроцессорной обработкой на osx, а не на linux - PullRequest
Новая
       7

segfault использует lapack_lite от numpy с многопроцессорной обработкой на osx, а не на linux

12 голосов
/ 27 марта 2012

Следующий тестовый код вызывает ошибки для меня на 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 "сообщение о проблеме" выскакивает, жалуясь на segfault как KERN_INVALID_ADDRESS at 0x0000000000000108; вот полный .

Если я запускаю его с n <= 32, он работает нормально;для любого n >= 33 происходит сбой.

Если я закомментирую вызов f(a), сделанный в исходном процессе, оба вызова на call_proc подойдут.Это все еще segfaults, если я вызываю f в другом большом массиве;если я вызываю его в другом небольшом массиве или если я вызываю f(large_array), а затем передаю f(small_array) другому процессу, он работает нормально.Они на самом деле не должны быть одной и той же функцией;np.inv(large_array) с последующим переходом на np.linalg.slogdet(different_large_array) также segfaults.

Все закомментированные np.linalg вещи в f вызывают сбои;np.dot(self.a, self.a.T).sum() и scipy.linalg.exp3m работают нормально.Насколько я могу судить, разница в том, что первый использует lapack_lite от numpy, а второй - нет.

Это происходит для меня на моем рабочем столе с

  • 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 работаютна других машинах под управлением

  • OSX 10.6.8 с Python 2.6.1 и numpy 1.2.1, связанных с 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

Я что-то здесь не так делаю?Что может быть причиной этого?Я не понимаю, как запуск функции на массиве, который становится засеченным и невысеченным, может привести к тому, что он позже станет причиной ошибки в другом процессе.

Обновление: когда я делаю дамп ядра, обратная трассировка находится внутри dispatch_group_async_f, интерфейс Grand Central Dispatch.Предположительно, это ошибка во взаимодействиях между Numpy / GCD и многопроцессорностью.Я сообщал об этом как ошеломляющая ошибка , но если у кого-то есть какие-либо идеи об обходных путях или, если на то пошло, как решить эту ошибку, это было бы очень признательно.:)

1 Ответ

5 голосов
/ 27 декабря 2012

Оказывается, что инфраструктура Accelerate, используемая по умолчанию в OSX , просто не поддерживает использование вызовов BLAS с обеих сторон fork. Нет реального способа справиться с этим, кроме ссылки на другой BLAS, и это не похоже на то, что они заинтересованы в исправлении.

...