segfault usando lapack_lite di NumPy con multiprocessing su osx, Linux non

Question

I seguenti segfaults Codice di prova per me su OSX 10.7.3, ma non altre macchine

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) 

uscita Esempio per uno di quelli segfaulty:

con un "rapporto problema" OSX spuntando lamentarsi di un segfault come KERN_INVALID_ADDRESS at 0x0000000000000108; here's a full one.

Se lo eseguo con n <= 32, funziona correttamente; per qualsiasi n >= 33, si arresta in modo anomalo.

Se commento la chiamata f(a) eseguita nel processo originale, entrambe le chiamate a call_proc vanno bene. È ancora segfaults se chiamo f su un altro grande array; se lo chiamo su un piccolo array diverso, o se chiamo f(large_array) e poi spengo f(small_array) in un altro processo, funziona perfettamente. In realtà non hanno bisogno di essere la stessa funzione; np.inv(large_array) seguito da passare a np.linalg.slogdet(different_large_array) anche segfaults.

Tutte le voci np.linalg commentate in f causano arresti anomali; np.dot(self.a, self.a.T).sum() e scipy.linalg.exp3m funzionano bene. Per quanto ne so, la differenza è che i primi usano numpacky lapack_lite e quest'ultimo no.

---

Questo accade per me, sul mio desktop con

• 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 e 2.7 sono le installazioni di sistema predefinite; Ho installato le versioni 3.2 manualmente dai tarball di origine. Tutti questi numpys sono collegati al sistema Accelerate quadro:

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

ottengo lo stesso comportamento su un altro Mac con una configurazione simile.

Ma tutte le opzioni per f lavoro su altre macchine in esecuzione

• OSX 10.6.8 con Python 2.6.1 e 1.2.1 NumPy legato per accelerare 4 e vecLib 268 (a parte che non è così avere SciPy o slogdet)
• Debian 6 con Python 3.2.2, NumPy 1.6.1, e SciPy 0.10.1 collegata al sistema ATLAS
• Ubuntu 11.04 con Python 2.7.1, 1.5.1 e NumPy SciPy 0.8. 0 collegato al sistema ATLAS

---

Sto facendo qualcosa di sbagliato qui? Cosa potrebbe causare questo? Non vedo come l'esecuzione di una funzione su una matrice numpy che viene decapitata e non avviata possa eventualmente causarla in seguito in un processo diverso.

---

Aggiornamento: quando faccio un core dump, il backtrace è dentro dispatch_group_async_f, l'interfaccia di Grand Central Dispatch. Presumibilmente questo è un bug nelle interazioni tra numpy/GCD e multiprocessing. Ho riportato questo come a numpy bug, ma se qualcuno ha qualche idea su soluzioni alternative o, se è per questo, come risolvere il bug, sarebbe molto apprezzato. :)

Answer 1

Si scopre che il framework Accelerate utilizzato per impostazione predefinita su OSX just doesn't support using BLAS calls on both sides of a fork. Non c'è un modo reale per gestire questo diverso dal collegamento a un BLAS diverso, e non sembra qualcosa a cui sono interessati a risolvere.