发布于2019-09-10 19:28 阅读(235) 评论(0) 点赞(0) 收藏(3)
以下测试代码在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)
其中一个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
; 这是一个完整的。
如果我运行它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而后者不使用numpy的lapack_lite。
在我的桌面上发生这种情况
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
在其他机器上运行的所有选项
slogdet
)我在这里做错了吗?什么可能导致这个?我没有看到如何在一个numpy数组上运行一个被pickle和unpickled的函数可能会导致它在以后的不同进程中出现段错误。
更新:当我进行核心转储时,回溯位于内部dispatch_group_async_f
,即Grand Central Dispatch界面。据推测,这是numpy / GCD与多处理之间相互作用的一个错误。我已将此报告为一个numpy bug,但如果有人对变通办法有任何想法,或者就此而言,如何解决这个bug,我们将不胜感激。:)
事实证明,默认情况下在OSX上使用的Accelerate框架不支持在a的两侧使用BLAS调用fork
。除了链接到不同的BLAS之外,没有真正的方法可以解决这个问题,而且它似乎并不像他们对修复感兴趣。
作者:黑洞官方问答小能手
链接:https://www.pythonheidong.com/blog/article/106634/7d1efbd198f96e658959/
来源:python黑洞网
任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任
昵称:
评论内容:(最多支持255个字符)
---无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事,而不是让内心的烦躁、焦虑,坏掉你本来就不多的热情和定力
Copyright © 2018-2021 python黑洞网 All Rights Reserved 版权所有,并保留所有权利。 京ICP备18063182号-1
投诉与举报,广告合作请联系vgs_info@163.com或QQ3083709327
免责声明:网站文章均由用户上传,仅供读者学习交流使用,禁止用做商业用途。若文章涉及色情,反动,侵权等违法信息,请向我们举报,一经核实我们会立即删除!