title: segfault using numpy's lapack_lite with multiprocessing on osx, not linux
body: <p>The following test code segfaults for me on OSX 10.7.3, but not other machines:</p>
  
  <pre><code>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) &gt; 1 else 50
  
      a = np.random.normal(0, 2, (n, n))
      f(a)
  
      call_proc(a)
      call_proc(a)
  </code></pre>
  
  <p>Example output for one of the segfaulty ones:</p>
  
  <pre><code>$ python2.7 test.py
  about to call
  result: -4.96797718087
  
  calling with multiprocessing
  about to call
  
  calling with multiprocessing
  about to call
  </code></pre>
  
  <p>with an OSX "problem report" popping up complaining about a segfault like <code>KERN_INVALID_ADDRESS at 0x0000000000000108</code>; <a href="https://gist.github.com/2209271">here's a full one</a>.</p>
  
  <p>If I run it with <code>n &lt;= 32</code>, it runs fine; for any <code>n &gt;= 33</code>, it crashes.</p>
  
  <p>If I comment out the <code>f(a)</code> call that's done in the original process, both calls to <code>call_proc</code> are fine. It still segfaults if I call <code>f</code> on a different large array; if I call it on a different small array, or if I call <code>f(large_array)</code> and then pass off <code>f(small_array)</code> to a different process, it works fine. They don't actually need to be the same function; <code>np.inv(large_array)</code> followed by passing off to <code>np.linalg.slogdet(different_large_array)</code> also segfaults.</p>
  
  <p>All of the commented-out <code>np.linalg</code> things in <code>f</code> cause crashes; <code>np.dot(self.a, self.a.T).sum()</code> and <code>scipy.linalg.exp3m</code> work fine. As far as I can tell, the difference is that the former use numpy's lapack_lite and the latter don't.</p>
  
  <hr />
  
  <p>This happens for me on my desktop with</p>
  
  <ul>
  <li>python 2.6.7, numpy 1.5.1</li>
  <li>python 2.7.1, numpy 1.5.1, scipy 0.10.0</li>
  <li>python 3.2.2, numpy 1.6.1, scipy 0.10.1</li>
  </ul>
  
  <p>The 2.6 and 2.7 are I think the default system installs; I installed the 3.2 versions manually from the source tarballs. All of those numpys are linked to the system Accelerate framework:</p>
  
  <pre><code>$ 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)
  </code></pre>
  
  <p>I get the same behavior on another Mac with a similar setup.</p>
  
  <p>But all of the options for <code>f</code> work on other machines running</p>
  
  <ul>
  <li>OSX 10.6.8 with Python 2.6.1 and numpy 1.2.1 linked to Accelerate 4 and vecLib 268 (except that it doesn't have scipy or <code>slogdet</code>)</li>
  <li>Debian 6 with Python 3.2.2, numpy 1.6.1, and scipy 0.10.1 linked to the system ATLAS</li>
  <li>Ubuntu 11.04 with Python 2.7.1, numpy 1.5.1 and scipy 0.8.0 linked to system ATLAS</li>
  </ul>
  
  <hr />
  
  <p>Am I doing something wrong here? What could possibly be causing this? I don't see how running a function on a numpy array that's getting pickled and unpickled can possibly cause it to later segfault in a different process.</p>
  
  <hr />
  
  <p><strong>Update:</strong> when I do a core dump, the backtrace is inside <code>dispatch_group_async_f</code>, the Grand Central Dispatch interface. Presumably this is a bug in the interactions between numpy/GCD and multiprocessing. I`ve reported this as <a href="http://projects.scipy.org/numpy/ticket/2091">a numpy bug</a>, but if anyone has any ideas about workarounds or, for that matter, how to solve the bug, it'd be greatly appreciated. :)</p>