segfault использует lapack_lite от numpy с многопроцессорной обработкой на osx, а не на linux
Следующий тестовый код segfaults для меня на 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.1Python 2.7.1, numpy 1.5.1, scipy 0.10.0python 3.2.2, numpy 1.6.1, scipy 0.10.12.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
работа на других машинах работает
slogdet
)Debian 6 с Python 3.2.2, numpy 1.6.1 и scipy 0.10.1, связанный с системой ATLASUbuntu 11.04 с Python 2.7.1, numpy 1.5.1 и scipy 0.8.0 связаны с системой ATLASЯ что-то здесь не так делаю? Что может быть причиной этого? Я не понимаю, как запуск функции на массиве, который становится засеченным и несортированным, может привести к тому, что позже он будет вызывать segfault в другом процессе.
Обновить: когда я делаю дамп ядра, обратная трассировка находится внутриdispatch_group_async_f
интерфейс Grand Central Dispatch. Предположительно, это ошибка во взаимодействиях между Numpy / GCD и многопроцессорностью. Я сообщил об этом кактупая ошибка, но если у кого-то есть какие-либо идеи об обходных путях или, если на то пошло, о том, как устранить ошибку, это было бы очень признательно. :)