Numpy: np.dot trava em alguns sistemas com numpy 1.14.5

Criado em 6 jul. 2018  ·  61Comentários  ·  Fonte: numpy/numpy

Em um de nossos sistemas, o seguinte snippet de código causa uma falha do interpretador Python:

import numpy as np
A = np.matrix([[1.], [3.]])
B = np.matrix([[2., 3.]])
np.dot(A, B)

Alguns detalhes:

  • Windows 10
  • Python 3.5.2 em um ambiente virtual
  • entorpecido 1.14.5

Em outros sistemas, este comando funciona perfeitamente.

00 - Bug

Todos 61 comentários

Onde você está conseguindo seu entorpecido? pip? Anaconda? O que np.show_config() diz?

Obrigado pela resposta. Eu instalei o numpy através do pip.

>>> import numpy as np
>>> np.show_config()
blas_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    library_dirs = ['C:\\projects\\numpy-wheels-jc1cl\\numpy\\build\\openblas']
    libraries = ['openblas']
    define_macros = [('HAVE_CBLAS', None)]
    language = f77
blis_info:
  NOT AVAILABLE
lapack_mkl_info:
  NOT AVAILABLE
openblas_info:
    library_dirs = ['C:\\projects\\numpy-wheels-jc1cl\\numpy\\build\\openblas']
    libraries = ['openblas']
    define_macros = [('HAVE_CBLAS', None)]
    language = f77
lapack_opt_info:
    library_dirs = ['C:\\projects\\numpy-wheels-jc1cl\\numpy\\build\\openblas']
    libraries = ['openblas']
    define_macros = [('HAVE_CBLAS', None)]
    language = f77
blas_opt_info:
    library_dirs = ['C:\\projects\\numpy-wheels-jc1cl\\numpy\\build\\openblas']
    libraries = ['openblas']
    define_macros = [('HAVE_CBLAS', None)]
    language = f77

Faz atualização para o tempo de execução do Microsoft Visual C mais recente na máquina
Socorro? Pode estar disponível no Windows Update ou em:
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

@pv obrigado pela dica, mas depois de instalar o último runtime de 2017 e reiniciar o sistema, o erro ainda existe.

Talvez não tenha nada a ver com o problema, mas o sistema afetado é um Windows 10 rodando em um KVM.

Quando executo o script de teste acima como t.py desta forma: python -u -m trace -t t.py , obtenho a seguinte saída antes da falha:

t.py(4): A = np.matrix([[1.], [3.]])
 --- modulename: defmatrix, funcname: __new__
defmatrix.py(213):         if isinstance(data, matrix):
defmatrix.py(221):         if isinstance(data, N.ndarray):
defmatrix.py(232):         if isinstance(data, str):
defmatrix.py(236):         arr = N.array(data, dtype=dtype, copy=copy)
defmatrix.py(237):         ndim = arr.ndim
defmatrix.py(238):         shape = arr.shape
defmatrix.py(239):         if (ndim > 2):
defmatrix.py(241):         elif ndim == 0:
defmatrix.py(243):         elif ndim == 1:
defmatrix.py(246):         order = 'C'
defmatrix.py(247):         if (ndim == 2) and arr.flags.fortran:
defmatrix.py(248):             order = 'F'
defmatrix.py(250):         if not (order or arr.flags.contiguous):
defmatrix.py(253):         ret = N.ndarray.__new__(subtype, shape, arr.dtype,
defmatrix.py(254):                                 buffer=arr,
defmatrix.py(255):                                 order=order)
 --- modulename: defmatrix, funcname: __array_finalize__
defmatrix.py(259):         self._getitem = False
defmatrix.py(260):         if (isinstance(obj, matrix) and obj._getitem): return
defmatrix.py(261):         ndim = self.ndim
defmatrix.py(262):         if (ndim == 2):
defmatrix.py(263):             return
defmatrix.py(256):         return ret
t.py(5): B = np.matrix([[2., 3.]])
 --- modulename: defmatrix, funcname: __new__
defmatrix.py(213):         if isinstance(data, matrix):
defmatrix.py(221):         if isinstance(data, N.ndarray):
defmatrix.py(232):         if isinstance(data, str):
defmatrix.py(236):         arr = N.array(data, dtype=dtype, copy=copy)
defmatrix.py(237):         ndim = arr.ndim
defmatrix.py(238):         shape = arr.shape
defmatrix.py(239):         if (ndim > 2):
defmatrix.py(241):         elif ndim == 0:
defmatrix.py(243):         elif ndim == 1:
defmatrix.py(246):         order = 'C'
defmatrix.py(247):         if (ndim == 2) and arr.flags.fortran:
defmatrix.py(248):             order = 'F'
defmatrix.py(250):         if not (order or arr.flags.contiguous):
defmatrix.py(253):         ret = N.ndarray.__new__(subtype, shape, arr.dtype,
defmatrix.py(254):                                 buffer=arr,
defmatrix.py(255):                                 order=order)
 --- modulename: defmatrix, funcname: __array_finalize__
defmatrix.py(259):         self._getitem = False
defmatrix.py(260):         if (isinstance(obj, matrix) and obj._getitem): return
defmatrix.py(261):         ndim = self.ndim
defmatrix.py(262):         if (ndim == 2):
defmatrix.py(263):             return
defmatrix.py(256):         return ret
t.py(6): print(np.dot(A, B))
 --- modulename: defmatrix, funcname: __array_finalize__
defmatrix.py(259):         self._getitem = False
defmatrix.py(260):         if (isinstance(obj, matrix) and obj._getitem): return
defmatrix.py(261):         ndim = self.ndim
defmatrix.py(262):         if (ndim == 2):
defmatrix.py(263):             return

Hmm,

este funciona

A = np.matrix([[1.], [3.]])
B = np.matrix([[2., 3.]])
print(np.dot(A.astype(np.float16), B.astype(np.float16)))

este trava

A = np.matrix([[1.], [3.]])
B = np.matrix([[2., 3.]])
print(np.dot(A.astype(np.float32), B.astype(np.float32)))

Qualquer ideia?

Depois de brincar com diferentes versões numpy, posso dizer que

  • numpy <= 1.13.1 não é afetado, enquanto
  • numpy> = 1.13.3 é afetado por este problema
  • numpy 1.13.2 não foi testado porque não há compilação em pypi

Não vejo nenhuma mudança óbvia que poderia levar a isso. Como o problema é específico desta instalação, pode ser útil ver se há algo especial sobre o ambiente, hardware, etc. Suspeito que haja um problema de biblioteca em algum lugar.

Em quais informações você está interessado?

OS Name Microsoft Windows 10 Pro
Version 10.0.16299 Build 16299
Other OS Description    Not Available
OS Manufacturer Microsoft Corporation
System Name <REMOVED>
System Manufacturer QEMU
System Model    Standard PC (i440FX + PIIX, 1996)
System Type x64-based PC
System SKU  
Processor   Common KVM processor, 1996 Mhz, 4 Core(s), 4 Logical Processor(s)
BIOS Version/Date   SeaBIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org, 4/1/2014
SMBIOS Version  2.8
Embedded Controller Version 255.255
BIOS Mode   Legacy
Platform Role   Desktop
Secure Boot State   Unsupported
PCR7 Configuration  Binding Not Possible
Windows Directory   C:\WINDOWS
System Directory    C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale  Austria
Hardware Abstraction Layer  Version = "10.0.16299.371"
User Name   Not Available
Time Zone   W. Europe Daylight Time
Installed Physical Memory (RAM) 4.00 GB
Total Physical Memory   4.00 GB
Available Physical Memory   1.94 GB
Total Virtual Memory    8.00 GB
Available Virtual Memory    5.27 GB
Page File Space 4.00 GB
Page File   C:\pagefile.sys
Virtualization-based security   Not enabled
Device Encryption Support   Reasons for failed automatic device encryption: TPM is not usable, PCR7 binding is not supported, Hardware Security Test Interface failed and device is not InstantGo, Un-allowed DMA capable bus/device(s) detected, Disabled by policy, TPM is not usable
A hypervisor has been detected. Features required for Hyper-V will not be displayed.    

Estou procurando diferenças com suas instalações de trabalho. Parece que o sistema básico é o Linux?

Funciona em:

  • todas as instalações físicas do Windows 10
  • em uma VM Windows 10 Hyper-V com host Windows 10

Não tenho nenhuma outra configuração semelhante do Windows 10 com a qual pudesse comparar o sistema afetado.

Parece que o sistema básico é o Linux?

Exatamente: Debian GNU / Linux 9 (extensão)

A mudança NumPy que provavelmente desencadeou isso foi a mudança para o OpenBLAS no Windows para 1.13.3. Vou supor que há algo que precisa de ajustes no ambiente numérico do KVM.

Também pode verificar se há um atlas dll flutuando.

Também pode verificar se há um atlas dll flutuando.

O que exatamente você quer dizer com esta frase?

Deve haver uma dll openblas para as versões posteriores, então estou me perguntando se pode haver alguma confusão com uma dll de atlas mais antiga. Provavelmente não. IIUC, numpy runs, está apenas retornando os resultados errados.

O Numpy é executado, mas para o exemplo acima, ele não executa nada novamente, mas causa um travamento.

Outra possibilidade é o OpenBLAS emitir uma instrução ilegal (SSE *) não suportada no ambiente KVM. Não sei o que está habilitado aí, dá para verificar?

Você pode controlar o OpenBlas a partir de variáveis ​​de ambiente. set OPENBLAS_VERBOSE=2 deve imprimir o modelo de processador padrão usado. Parece que o convidado deve usar o mesmo modelo do hardware host real, então há set OPENBLAS_CORETYPE=nehalem por exemplo, se isso for correto para sua máquina host. O NumPy se comporta corretamente na máquina host? Se sim, você pode usar a configuração detalhada para descobrir o que o convidado deve usar

Mais informações sobre este problema?

O problema ainda existe, mas eu ainda não fui capaz de testar as coisas que @mattip e você mencionou. Não poderei fazer isso nas próximas duas semanas, mas farei isso depois.

OK, obrigado.

@ m55c55 Você conseguiu depurar isso mais?

Olá,
Posso confirmar esse problema e posso ajudar fornecendo outro caso de uso ...

Tenho um comportamento muito semelhante na minha máquina (instalação nova do Linux):

Linux 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 18.04.1 LTS

numpy (1.15.4)

>>> np.show_config()
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]

Meu script python:

import numpy as np
A = np.random.randn(100, 3000)
B = np.random.randn(3000, 100)
np.dot(B, A)

O script não trava com matrizes muito pequenas.

No entanto, a falha é realmente crítica: a máquina reinicia instantaneamente e muitos arquivos são corrompidos (meu bash e o módulo numpy quebraram durante minha investigação).

Presumo que você queira dizer np.dot(B, A.T) ? Como você conseguiu o NumPy? Se você mesmo construiu, qual versão do OpenBLAS?

Não, deve ser np.dot(B, A) ter dimensões alinhadas.

Tentei ficar entorpecido com pip (1.15.4)

➜  ~ pip3 install numpy
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/ff/7f/9d804d2348471c67a7d8b5f84f9bc59fd1cefa148986f2b74552f8573555/numpy-1.15.4-cp36-cp36m-manylinux1_x86_64.whl

E também tentei em repositórios do Ubuntu (1.13.3)

➜  ~ apt-cache show python3-numpy
Package: python3-numpy
Architecture: amd64
Version: 1:1.13.3-2ubuntu1
Priority: optional
Section: python
Source: python-numpy
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Sandro Tosi <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 10670
Provides: python3-f2py, python3-numpy-abi9, python3-numpy-api11, python3-numpy-dev, python3.6-numpy
Depends: python3 (<< 3.7), python3 (>= 3.6~), python3.6:any, python3:any (>= 3.4~), libblas3 | libblas.so.3, libc6 (>= 2.14), liblapack3 | liblapack.so.3
Suggests: gcc (>= 4:4.6.1-5), gfortran, python-numpy-doc, python3-dev, python3-nose (>= 1.0), python3-numpy-dbg
Filename: pool/main/p/python-numpy/python3-numpy_1.13.3-2ubuntu1_amd64.deb
Size: 1942804
MD5sum: 7b84ea9967f987a292b64f5bc5b6d65f
SHA1: 73fd8354b7106ac81b8add37947173aad515a9d5
SHA256: 3098ad88b8404cbeee66cc6eef96b13ea87eda848900d7cb754fd0bf280741bf

Tentei em outro computador rodando ubuntu 18 e pip instalado numpy ... e não consigo reproduzir a falha. Não tenho certeza do que está acontecendo !

Olá, encontrei este bug ao executar a função corrcoef. Eu investiguei e descobri que posso reproduzir a falha com a seguinte chamada np.dot(np.array([[0], [0]]), np.array([0, 0]).conj())

Estou executando o Windows 10 em um ambiente anaconda.

np.__version__

1.14.2

np.show_config ()

mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\lib', 'C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\include']
blas_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\lib', 'C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\include']
blas_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\lib', 'C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\include']
lapack_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\lib', 'C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\include']
lapack_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2016.4.246\\windows\\mkl\\lib', 'C:/Users/tommassino/AppData/Local/Continuum/Anaconda3/envs/project-conda\\Library\\include']

@Tommassino não pode reproduzir. Tem certeza de que essas são as formas que estão falhando?
Este problema é sobre a execução dentro de uma VM, se sua configuração for diferente, abra um novo problema.

>>> import sys
>>> print(sys.version)
3.6.6 (default, Sep 12 2018, 18:26:19) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]
>>> import numpy as np
>>> np.__version__
'1.14.2'
>>> np.dot(np.array([[0], [0]]), np.array([0, 0]).conj())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: shapes (2,1) and (2,) not aligned: 1 (dim 1) != 2 (dim 0)

@mattip Ah, desculpe, não percebi que isso estava relacionado especificamente a um ambiente de VM, pois só foi mencionado nos posts a seguir. Algumas das outras respostas parecem mencionar o problema que ocorre em não-vms. Meu erro com o comando np.dot, copiei os arrays do meu depurador incorretamente.

>>> import sys
>>> import numpy as np
>>> print(sys.version)
3.6.6 | packaged by conda-forge | (default, Jul 26 2018, 11:48:23) [MSC v.1900 64 bit (AMD64)]
>>> print(np.__version__)
1.14.2
>>> X = np.array([0., 0.])
>>> X_T = np.array([0., 0.])
>>> print(X)
[0. 0.]
>>> print(X_T)
[0. 0.]
>>> print(np.dot(X, X_T.conj()))
Process finished with exit code 2

No entanto, já descobri que isso pode estar relacionado ao carregamento incorreto dos nativos do mkl, então isso pode ser outro problema.

@Tommassino Você também ficou entorpecido com a conda?

@ oleksandr-pavlyk: alguma ideia?

@Tommassino Você também ficou entorpecido com a conda?

Desculpe pelo atraso na resposta, feriados ... Sim, estou usando um conda numpy

> conda list --no-pip | grep numpy
numpy                     1.14.2           py36h5c71026_1

No entanto, como mencionei acima, quando atualizei o mkl ( conda update mkl ), o problema foi embora.

Acho que podemos fechar isso? @Khemal, já que você está executando o Linux, pode postar a saída de https://gist.github.com/seberg/ce4563f3cb00e33997e4f80675b80953 na caixa onde ocorre o travamento? Isso pode nos dizer o que há de errado, já que isso certamente está relacionado ao blas.

A menos que realmente haja algum problema de contagem de referência, eu ficaria surpreso se isso não atingisse também outras pessoas aleatoriamente.

Oi.

Eu coletei algumas informações sobre o assunto.

Python 3.6.7
entorpecido (1.15.4)

(.kfr-test-env) root<strong i="9">@whatever</strong>:/app# gdb python3
(gdb) run testcode.py 
Starting program: /app/.kfr-test-env/bin/python3 testcode.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3c1b700 (LWP 29704)]

Thread 1 "python3" received signal SIGILL, Illegal instruction.
0x00007ffff4a5c204 in dgemm_oncopy_OPTERON_SSE3 () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so
(gdb) bt
#0  0x00007ffff4a5c204 in dgemm_oncopy_OPTERON_SSE3 () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so
#1  0x00007ffff6520630 in ?? () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so
#2  0x00000000000000e0 in ?? ()
#3  0x00007ffff41275db in dgemm_tt () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so
#4  0x00007ffff4052088 in cblas_dgemm () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so
#5  0x00007ffff676d28f in ?? () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so
#6  0x00007ffff6732c36 in ?? () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so
#7  0x00007ffff673400a in ?? () from /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so
#8  0x00000000005030d5 in _PyCFunction_FastCallDict (kwargs=<optimized out>, nargs=<optimized out>, args=<optimized out>, 
    func_obj=<built-in method dot of module object at remote 0x7ffff6a535e8>) at ../Objects/methodobject.c:231
#9  _PyCFunction_FastCallKeywords (kwnames=<optimized out>, nargs=<optimized out>, stack=<optimized out>, func=<optimized out>) at ../Objects/methodobject.c:294
#10 call_function.lto_priv () at ../Python/ceval.c:4837
#11 0x0000000000506859 in _PyEval_EvalFrameDefault () at ../Python/ceval.c:3335
#12 0x0000000000504c28 in PyEval_EvalFrameEx (throwflag=0, f=Frame 0xadeb18, for file testcode.py, line 10, in <module> ()) at ../Python/ceval.c:4166
#13 _PyEval_EvalCodeWithName.lto_priv.1761 () at ../Python/ceval.c:4166
#14 0x0000000000506393 in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=<optimized out>, 
    globals=<optimized out>, _co=<optimized out>) at ../Python/ceval.c:4187
#15 PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>) at ../Python/ceval.c:731
#16 0x0000000000634d52 in run_mod () at ../Python/pythonrun.c:1025
#17 0x0000000000634e0a in PyRun_FileExFlags () at ../Python/pythonrun.c:978
#18 0x00000000006385c8 in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:419
#19 0x00000000006387a5 in PyRun_AnyFileExFlags () at ../Python/pythonrun.c:81
#20 0x000000000063915a in run_file (p_cf=0x7fffffffe2fc, filename=<optimized out>, fp=<optimized out>) at ../Modules/main.c:340
#21 Py_Main () at ../Modules/main.c:810
#22 0x00000000004a6f10 in main (argc=2, argv=0x7fffffffe4f8) at ../Programs/python.c:69

@seberg este é o resultado:

Probing Multiarray
------------------
OpenBLAS:
    num threads: 2
    version info: DYNAMIC_ARCH NO_AFFINITY Opteron MAX_THREADS=64

Probing Linalg
--------------
OpenBLAS:
    num threads: 2
    version info: DYNAMIC_ARCH NO_AFFINITY Opteron MAX_THREADS=64

LDD information:
----------------
running: ldd /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so
    linux-vdso.so.1 (0x00007ffe941ef000)
    libopenblasp-r0-8dca6697.3.0.dev.so => /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so (0x00007f9319cea000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f931994c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f931972d000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f931933c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f931c800000)
    libgfortran-ed201abd.so.3.0.0 => /app/.kfr-test-env/lib/python3.6/site-packages/numpy/core/../.libs/libgfortran-ed201abd.so.3.0.0 (0x00007f9319042000)
running: ldd /app/.kfr-test-env/lib/python3.6/site-packages/numpy/linalg/_umath_linalg.cpython-36m-x86_64-linux-gnu.so
    linux-vdso.so.1 (0x00007ffda69d5000)
    libopenblasp-r0-8dca6697.3.0.dev.so => /app/.kfr-test-env/lib/python3.6/site-packages/numpy/linalg/../.libs/libopenblasp-r0-8dca6697.3.0.dev.so (0x00007f12097c1000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f12095a2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12091b1000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1208e13000)
    libgfortran-ed201abd.so.3.0.0 => /app/.kfr-test-env/lib/python3.6/site-packages/numpy/linalg/../.libs/libgfortran-ed201abd.so.3.0.0 (0x00007f1208b19000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f120c0ee000)

@mattip Eu tentei as coisas variáveis ​​de ambiente, que você mencionou:

Com o os.environ["OPENBLAS_CORETYPE"] = "nehalem" funciona, mas sem ele não funciona.

import os
os.environ["OPENBLAS_VERBOSE"] = "2"
os.environ["OPENBLAS_CORETYPE"] = "nehalem"
import numpy as np

A = np.matrix([[1.], [3.]])
B = np.matrix([[2., 3.]])
ret = np.dot(A, B)
print(ret)

@kfrendrich Acho que você também está em uma máquina virtual ou algo assim? Caso contrário, talvez haja um problema com a detecção de CPU no OpenBLAS? Se esta for uma máquina virtual, acho que você pode apenas ter que usar essas variáveis ​​de ambiente.

@seberg sim, é uma máquina virtual

Isso soa como um bug na maneira como o OpenBLAS está detectando a cpu. Você poderia relatar a eles? Não consegui encontrar kvm problema aberto, mas existem alguns problemas fechados

Sim, vou relatá-los em breve.

Isso ainda se reproduz?

A mesma falha com o numpy 1.17.3.

$ python
>>> import numpy as np
>>> A = np.matrix([[1.0], [3.0]])
>>> B = np.matrix([[2.0, 3.0]])
>>> ret = np.dot(A, B)
Illegal instruction (core dumped)

Este é provavelmente o motivo do erro que peguei - o Python morre com a "instrução ilegal (core despejado)" ao tentar executar:

import matplotlib.pyplot as plt
fig = plt.figure(figsize=(10,10))

Solução proposta:

import os
os.environ["OPENBLAS_VERBOSE"] = "2"
os.environ["OPENBLAS_CORETYPE"] = "nehalem"
import numpy as np

não funciona :(

Aqui está a história completa e a configuração:

$ python
Python 3.6.8 (default, Oct  9 2019, 14:04:01)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import numpy as np
>>> print(sys.version)
3.6.8 (default, Oct  9 2019, 14:04:01)
[GCC 8.3.0]
>>> print(np.__version__)
1.17.3
>>> np.show_config()
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]

Informações da CPU (esta é a máquina virtual):

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2199.998
cache size      : 4096 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm pti fsgsbase smep erms
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2199.998
cache size      : 4096 KB
physical id     : 1
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm pti fsgsbase smep erms
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2199.998
cache size      : 4096 KB
physical id     : 2
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm pti fsgsbase smep erms
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2199.998
cache size      : 4096 KB
physical id     : 3
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm pti fsgsbase smep erms
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

@prokulski como você instalou o openblas? Qual versão você usa? Quando você verifica seu repositório github, você pode saber qual versão deve se comportar de que maneira.

openblas foi instalado automaticamente (como dependência de algo). Tentei removê-lo e instalar novamente (via apt install) - não ajudou

Presumo que isso também trava com matrizes regulares (em vez de np.matrix ). Seria bom eliminar o código obsoleto da depuração. Isso se comporta em seu sistema?

>>> import numpy as np
>>> A = np.array([[1.0], [3.0]])
>>> B = np.array([[2.0, 3.0]])
>>> ret = np.dot(A, B)

E se

>>> import numpy as np
>>> A = np.array([[1.0], [3.0]])
>>> B = np.array([[2.0, 3.0]])
>>> ret = np.matmul(A, B)

Presumo que isso também trava com matrizes regulares (em vez de np.matrix ). Seria bom eliminar o código obsoleto da depuração. Isso se comporta em seu sistema?

>>> import numpy as np
>>> A = np.array([[1.0], [3.0]])
>>> B = np.array([[2.0, 3.0]])
>>> ret = np.dot(A, B)

Crachesh com "Instrução ilegal (core despejado)"

>>> import numpy as np
>>> A = np.array([[1.0], [3.0]])
>>> B = np.array([[2.0, 3.0]])
>>> ret = np.matmul(A, B)

Dá:

>>> ret
array([[2., 3.],
       [6., 9.]])

@prokulski como você instalou o openblas? Qual versão você usa? Quando você verifica seu repositório github, você pode saber qual versão deve se comportar de que maneira.

openblas foi instalado automaticamente (como dependência de algo). Tentei removê-lo e instalar novamente (via apt install) - não ajudou

Isso ainda não responde à pergunta sobre o número da versão.

Eles mudaram o sistema sobre como a biblioteca detecta o tipo de CPU. Melhor contatá-los diretamente, já que o numpy usa apenas a biblioteca. Veja, por exemplo, meu problema https://github.com/xianyi/OpenBLAS/issues/2067 como referência.

$ apt list *blas* | grep installed
libblas-dev/bionic,now 3.7.1-4ubuntu1 amd64 [installed,automatic]
libblas3/bionic,now 3.7.1-4ubuntu1 amd64 [installed,automatic]
libgslcblas0/bionic,now 2.4+dfsg-6 amd64 [installed,automatic]

Eu instalei o libopenblas-dev e agora é:

$ apt list *blas* | grep installed
libblas-dev/bionic,now 3.7.1-4ubuntu1 amd64 [installed,automatic]
libblas3/bionic,now 3.7.1-4ubuntu1 amd64 [installed,automatic]
libgslcblas0/bionic,now 2.4+dfsg-6 amd64 [installed,automatic]
libopenblas-base/bionic,now 0.2.20+ds-4 amd64 [installed,automatic]
libopenblas-dev/bionic,now 0.2.20+ds-4 amd64 [installed]

Pitão:

$ python
Python 3.6.8 (default, Oct  9 2019, 14:04:01)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> A = np.matrix([[1.0], [3.0]])
>>> B = np.matrix([[2.0, 3.0]])
>>> ret = np.dot(A, B)
Illegal instruction (core dumped)

Você pode tentar definir OPENBLAS_CORETYPE para a CPU do sistema host. O numpy que você obtém com pip install do PyPI contém OpenBLAS 0.3.7, que deve conter uma correção para isso. Se você escolher usar pip install e não estiver usando um virtualenv, certifique-se de usar pip install --upgrade --user numpy para evitar conflitos com o python do seu sistema.

Para determinar a versão do OpenBLAS, você pode usar este código, que relatará a versão do OpenBLAS 0.3.5 e superior

    import numpy
    import ctypes

    dll = ctypes.CDLL(numpy.core._multiarray_umath.__file__)
    get_config = dll.openblas_get_config
    get_config.restype=ctypes.c_char_p
    res = get_config()
    print('OpenBLAS get_config returned', str(res))

@mattip seu código fornece "OpenBLAS get_config retornou b'OpenBLAS 0.3.7 DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS = 64 '"

Definir OPENBLAS_CORETYPE como Haswell (minúsculas, maiúsculas, o que for) não ajuda - eu tentei isso antes.

Acho que o problema está na máquina virtual KVM e na detecção de CPU ruim no blas. Estranho, que alguns dias antes tudo estava ok ...

Acho que Haswell é o valor errado para você, mas uma rápida pesquisa no Google não está trazendo boas respostas para detectar a CPU do host uma vez dentro de uma máquina virtual.

Acho que Haswell é o valor errado para você, mas uma rápida pesquisa no Google não está trazendo boas respostas para detectar a CPU do host uma vez dentro de uma máquina virtual.

Sim. Skylake seria melhor (se você ver cpuinfo), mas também não ajuda. Estou preso.
https://github.com/numpy/numpy/milestone/69 dá esperança;)

Tente estes como especificadores de kernel OpenBLAS, algum deles funciona?

export OPENBLAS_CORETYPE=prescott

e dunnington, penryn, core2, nehalem, sandybridge

Todo mundo morre.

O KVM permite definir o tipo de cpu? Foi atualizado recentemente?

Apenas para confirmar se a configuração do núcleo funciona corretamente, adicione:

export OPENBLAS_VERBOSE=2
export OPENBLAS_CORETYPE=prescott
python -c 'import numpy as np; A = np.array([[1.0], [3.0]]); B = np.array([[2.0, 3.0]]); print(np.dot(A, B))'

Eu recebo:

Core: Prescott
[[2. 3.]
 [6. 9.]]

O suporte disse que nada mudou com os processadores da última vez.

Também puxei e iniciei docker image jupyter / tensorflow-notebook nesta máquina e o exemplo np.dot () executado no Jupyter falha da mesma forma. Então, eu acho que isso é problema de hardware?

@prokulski se você usar o código do comentário acima , você obtém a saída Core: Prescott antes da instrução ilegal?

Como isso parece ser específico para o seu hardware, estou removendo-o do marco 1.18.

Eu tenho "Core: Presscot" e depois a matriz 2x2 e nenhuma instrução ilegal.

Sem a linha "export OPENBLAS_CORETYPE = prescott", há instrução ilegal e nenhuma matriz.

Parece que de alguma forma a rotina para detectar sua CPU dentro do OpenBLAS é confundida com seu KVM. Você poderia relatar no rastreador de problemas do

Você provavelmente pode ajudar o OpenBLAS percorrendo todos os tipos de núcleo listados acima e descobrindo quais travam.

Esta página foi útil?
0 / 5 - 0 avaliações