2012-03-26 24 views
11

निम्नलिखित परीक्षण कोड segfaults लिनक्स पर OSX 10.7.3 नहीं है, लेकिन नहीं अन्य मशीनों: segfaulty लोगों में से एक के लिएOSX पर बहु ​​के साथ numpy के lapack_lite का उपयोग कर segfault, मेरे लिए

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 

एक ओएसएक्स "समस्या रिपोर्ट" के साथ 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) से भी गुजरने के बाद।

में 0 टिप्पणी की गई सभी टिप्पणियां f क्रैश का कारण बनती हैं; np.dot(self.a, self.a.T).sum() और scipy.linalg.exp3m ठीक काम करते हैं। जहां तक ​​मैं कह सकता हूं, अंतर यह है कि पूर्व का उपयोग numpy के lapack_lite और बाद वाला नहीं है।


यह, साथ

  • अजगर 2.6.7, numpy 1.5.1
  • अजगर 2.7.1, numpy 1.5.1 मेरे डेस्कटॉप पर मेरे लिए होता है scipy 0.10.0
  • पायथन 3.2.2, numpy 1.6.1, scipy 0.10.1

2.6 और 2.7 मुझे लगता है कि डिफ़ॉल्ट सिस्टम स्थापित करता है; मैंने स्रोत संस्करणों से मैन्युअल रूप से 3.2 संस्करण स्थापित किए हैं। उन सभी numpys सिस्टम से जुड़े हैं ढांचे को तेज करें:

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

मुझे एक समान मैक पर एक ही मैक पर एक ही व्यवहार मिलता है।

लेकिन अन्य मशीनों पर f काम के लिए सभी विकल्पों को अजगर 2.6.1 और 1.2.1 numpy में तेजी लाने के लिए 4 जुड़ा हुआ है और vecLib 268 (सिवाय इसके कि यह नहीं है के साथ

  • OSX 10.6.8 चल है scipy या slogdet)
  • डेबियन 6 अजगर 3.2.2, numpy 1.6.1, और scipy 0.10.1 पायथन 2.7.1, numpy 1.5.1 और scipy 0.8 के साथ प्रणाली एटलस
  • उबंटू 11.04 से जुड़ा हुआ है। 0 सिस्टम ATLAS
01 से जुड़ा हुआ है

क्या मैं यहां कुछ गलत कर रहा हूं? संभवतः यह क्या हो सकता है? मैं नहीं देखता कि एक नुकीले सरणी पर एक फ़ंक्शन कैसे चला रहा है जो मसालेदार और अनपिक्क हो रहा है, संभवतः इसे बाद में एक अलग प्रक्रिया में segfault कर सकता है।


अद्यतन: जब मैं एक कोर डंप करना, पश्व-अनुरेखन अंदर dispatch_group_async_f, ग्रांड सेंट्रल डिस्पैच इंटरफेस है। संभवतः यह numpy/जीसीडी और मल्टीप्रोसेसिंग के बीच बातचीत में एक बग है। मैंने इसे a numpy bug के रूप में रिपोर्ट किया है, लेकिन अगर किसी के पास कामकाज के बारे में कोई विचार है या, उस मामले के लिए, बग को कैसे हल किया जाए, तो इसकी सराहना की जाएगी। :)

+0

परिपक्व लाइब्रेरी के रूप में, numpy * को कभी भी विभाजन की गलती नहीं होनी चाहिए या अन्यथा वर्तमान प्रक्रिया को निरस्त करना चाहिए। क्या आपने http://projects.scipy.org/numpy पर एक बग रिपोर्ट सबमिट की है? – Collin

+0

हाँ, मैंने इसकी सूचना दी: http://projects.scipy.org/numpy/ticket/2091। टिकट ने बिल्कुल शून्य प्रतिक्रिया देखी है, और मैंने ओएसएक्स पर उस कोड को चलाने से रोक दिया है। मैं 10.8 पर numpy मास्टर के साथ फिर से परीक्षण करूँगा और अगले हफ्ते एक अपडेट पोस्ट करूंगा। – Dougal

उत्तर

5

यह पता चला है कि ओएसएक्स just doesn't support using BLAS calls on both sides of a fork पर डिफ़ॉल्ट रूप से उपयोग किए गए फ्रेमवर्क को तेज करें। एक अलग बीएलएएस से जोड़ने के अलावा इस से निपटने का कोई वास्तविक तरीका नहीं है, और यह ऐसा कुछ नहीं लगता है जिसे वे फिक्सिंग में रूचि रखते हैं।

+2

पायथन 3.4 में मल्टीप्रोसेसिंग के लिए 'फोर्सरवर' मोड होगा जो मल्टीप्रोसेसिंग के साथ एक्सीलरेट या ओपनबीएलएस का उपयोग करना संभव बनाता है। – ogrisel