failing unittests / crashes on GNU/Linux Debian sparc arch (in threaded mode)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. happens with 1.4.2 and 2.0.1 (debian experimental)
2. on sparc boxes (but necessarily all of them)
3. some times just a test failure some times a crash, e.g.

 http://www.onerussian.com/tmp/numexpr-crash.txt

Here is the script with rudimentary evaluate which reveals the failing tests 
and crash:

import numpy as np
from numpy.testing import *
from numpy import arange
import numexpr
from numexpr import E, NumExpr, evaluate, disassemble, use_vml

#numexpr.set_num_threads(1)

print "LIOOP"

for r in xrange(1000000000):
        x = arange(800000., 1e6)
        y = evaluate("x")
        print r
        if not np.all( x == y):
            print "FAILED on %d run:" % r
            print len(np.where (x!=y)[0])
            print (np.where (x!=y)[0])
            print x[x!=y]
            print (x-y)[x!=y]
            #import pdb; pdb.set_trace()
        #assert_array_equal(x, y)

if threading is disabled above -- then tests failures and crash goes away.

could you please advise on directions to troubleshoot?

Original issue reported on code.google.com by yarikop...@gmail.com on 9 Apr 2012 at 6:34

[GoogleCodeExporter]

See also https://groups.google.com/forum/?fromgroups#!topic/numexpr/c6wc32p5i78

Original comment by a.valent...@gmail.com on 9 Apr 2012 at 7:10

[GoogleCodeExporter]

right... ok - if more context is needed, disabling PyDataMem_FREE(self->data);  
in numpy/core/src/multiarray/arrayobject.c:209 leads to obvious memory leaks 
but completely eliminates the failing tests/crash

Original comment by yarikop...@gmail.com on 9 Apr 2012 at 7:16

[GoogleCodeExporter]

And FWIW -- the same with current numpy master

commit b6b5ba1387d754a595838bab4dbdd80f61e0d63e
Author: Ralf Gommers <ralf.gommers@googlemail.com>
Date:   Thu Apr 5 21:40:49 2012 +0200

    BUG: fix regression for indexing chararrays with empty list. Closes #1948.

Original comment by yarikop...@gmail.com on 9 Apr 2012 at 7:55

[GoogleCodeExporter]

The use of multithreading has been disable on the Sparc machines.  One should 
still try to fix this in the future, so leaving this open.

Original comment by fal...@gmail.com on 26 Apr 2013 at 11:44

• Changed state: Accepted

[GoogleCodeExporter]

BTW, the multithreading disabling for Sparc happened in rev 9898bc327cba.

Original comment by fal...@gmail.com on 26 Apr 2013 at 11:45