Numpy: Error en Azure CI (instancia de Windows) con numpy 1.19.0

¿Falla constantemente o solo de vez en cuando? ¿Tiene desarrolladores de Windows que puedan intentar construir el proyecto en una máquina local?

Hola,
¡Gracias!

Falló constantemente muchas veces ... en ese momento pensé en preguntar a los desarrolladores de Azure (mi suposición inicial fue que tal vez algo había cambiado en la configuración de sus máquinas virtuales).

Este enlace tiene la discusión que tuve con un desarrollador de Microsoft que descubrió que el problema podría haber sido numpy: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comentario -1119179

Desafortunadamente, no tengo a nadie que pueda intentar construir el proyecto en una máquina local de Windows :(

Entonces necesitaremos un conjunto claro de pasos para reproducir

¿Funcionaría azure-pipelines.yml?

Esto es lo que usamos (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml) comentado en este momento ... puedes ver que es una configuración bastante estándar, usando Python 3.7 , instalando dependencias en el archivo requirements-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) y luego ejecutando las pruebas.

Como ya mencioné, si comento esto y fuerzo numpy 1.18.5, todo se ejecuta, parece que es el nuevo 1.19 para romper

¿Cuál es la versión principal y secundaria de Windows de la imagen que se ejecuta en Azure? es decir, ¿qué imprime systeminfo para OS Version ?

Podría encontrar los detalles de las máquinas virtuales de Azure utilizadas en Azure Pipelines aquí: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml y el enlace a software instalado https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

No estoy seguro de cómo ejecutar systeminfo en una canalización de Azure, ¿alguna sugerencia?

Se ejecuta desde la línea de comandos y vuelca la salida al terminal, por lo que puede agregarlo a su ejecución como un comando.

Puede hacer esto en un PR que se ejecuta en CI para ver lo que dice. Estoy preguntando porque ha habido problemas con la compilación 19041 de Windows y pip NumPy.

La respuesta estaba en el segundo enlace:

Versión del SO: 10.0.17763 Build 1282

Entonces mi idea no da frutos.

Dice que sabe que hay algunos problemas con las últimas ruedas de pip para Windows, ¿probablemente está relacionado con eso?

En realidad, es (probablemente) un error de Windows introducido en 19041. Pero estás en una versión mucho más antigua, así que este no es el problema.

No afecta a Conda NumPy, solo pip NumPy porque parece haber algún problema con Windows y OpenBlas.

Ya veo :) Recibí un correo electrónico de que se ha publicado la versión 1.9.1. Voy a intentar reactivar la canalización de Azure que ahora instalaría la última versión y veré si funciona, se lo haré saber

Lamentablemente todavía falla con 1.19.1 https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=45&view=logs&j=50448a2f-9550-51a0-b6c4-5ec64224dd81&t=a6a6804f-7af1-5f4653-b76db-67 :(

Un error en OpenBlas.

Aquí hay un ejemplo de reproducción:

import numpy as np
nr = 12000
v = np.random.randn(nr) + 1j * np.random.randn(nr)
np.vdot(v, v)
# also access violations
v @ v
# also access violations

La información de depuración sin símbolos es:

Exception thrown at 0x0000000068DBB8F0 (libopenblas.NOIJJG62EMASZI6NYURL6JBKM4EVBGM7.gfortran-win_amd64.dll)
in python.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Tenga en cuenta que la matriz tiene que ser bastante grande (10k pasa, 12k no) para activar el error.

Comprobación rápida:

$env:OPENBLAS_VERBOSE=2
$env:OPENBLAS_CORETYPE=Prescott

pasa pero el kernel predeterminado ( Zen ), así como Haswell y Sandybridge , ambos tienen violaciones de acceso.

Tal vez valga la pena comprobar ese numpy HEAD, que usa un OpenBLAS 0.3.10 más nuevo, también falla. ¿O quizás ya lo hiciste?

@mattip no No lo había probado todavía. ¿Te refieres a instalar Bumpy directamente desde el maestro con pip install git+https://github.com/numpy/numpy ? Puedo intentarlo :)

Y a su pregunta @bashtage (¿Las pruebas fallidas usan numba? Numba 0.50 tiene un error en algunas versiones de Windows en las que hace uso incorrecto de un intrínseco no disponible. Esto me causó fallas en otro proyecto). email pero parece que no puedo ver en este hilo ... la prueba que falla usa las operaciones numpy y pyfftw . Cuando se bloquea con este mensaje repentino, es difícil saber en qué línea se bloquea realmente. Pero no creo que pyfftw use numba en absoluto, al menos no es una de sus dependencias

Acabo de intentar instalar HEAD of NumPy directamente desde el repositorio de GitHub y la compilación de Windows se ejecuta hasta su finalización, sin bloqueo repentino: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Curiosamente, algunas bibliotecas que tienen NumPy como dependencia no parecen instalarse correctamente (no estoy seguro de por qué) y algunas pruebas fallan para todos los sistemas operativos, pero al menos no es un bloqueo completo como antes ...

No hay error al usar todas las noches:

pip install -i https://pypi.anaconda.org/scipy-wheels-nightly/simple numpy

Intenté instalar HEAD of NumPy directamente desde el repositorio de GitHub

Esto no tiene OpenBLAS a menos que lo construyas explícitamente. De forma predeterminada, obtienes un BLAS lento y genérico con pip install git+https://github.com/numpy/numpy.git .

Parece que es posible que queramos actualizar OpenBLAS para 1.19.2, así que marque esto.

Creo que podría estar experimentando el mismo problema en la última --pre build (numpy-1.20.0.dev0 + a0028bc) en Azure :

Current thread 0x000003d0 (most recent call first):
  File "<__array_function__ internals>", line 5 in dot
  File "D:\a\1\s\mne\minimum_norm\inverse.py", line 732 in _assemble_kernel

La línea en cuestión es simplemente:

K = np.dot(eigen_leads, trans)

Si ayuda, podría intentar guardar las matrices en el disco y sacarlas a través de un artefacto de Azure.

Eso parece. Estás usando el mismo pre que yo tenía funcionando correctamente.

Es posible que desee agregar

$env:OPENBLAS_VERBOSE=2

o

set OPENBLAS_VERBOSE=2

a su plantilla para saber qué kernel se está utilizando.

Si ayuda, podría intentar guardar las matrices en el disco y sacarlas a través de un artefacto de Azure.

Probablemente bastaría con conocer los tipos y dimensiones.

De acuerdo, reproducido en una sola ejecución de solo la prueba fallida con solo numpy + scipy + matplotlib + pytest (y deps) que escribe las matrices que se multiplican y luego carga los artefactos, aquí está la pestaña de artefactos:

https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=8330&view=artifacts&type=publishedArtifacts

El último .npz debería ser el que falla (27 MB). Localmente en Linux, puntúa muy bien:

>>> import numpy as np
>>> data = np.load('1595525222.9485037.npz')
>>> np.dot(data['a'], data['b']).shape
(23784, 305)
>>> data['a'].shape, data['a'].dtype, data['b'].shape, data['b'].dtype
((23784, 305), dtype('>f4'), (305, 305), dtype('float64'))
>>> data['a'].flags, data['b'].flags
(  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
,   C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
)

Trabajando para hacer que el OPENBLAS_VERBOSE funcione, pero parece que cada vez que uso pytest -s para no capturar la salida que realmente pasa. Sin embargo, esto podría ser una casualidad, ya veremos ...

Es curioso, ahora también lo veo con el reproductor de arriba.

No lo veo si configuro OPENBLAS_CORETYPE en Prescott o Nehalem. Lo veo con Zen, Sandybridge y Haswell.

No puedo reproducir localmente usando los datos de su npz en Windows.

No puedo reproducir localmente usando los datos de su npz en Windows.

FWIW en Azure Puedo reproducirlo con los datos save-load-round-tripped, porque ahora falla en la penúltima línea en el código ejecutado aquí:

    import mne, os.path as op, time
    fname = op.join(op.dirname(mne.__file__), '..', 'bad', f'{time.time()}.npz')
    np.savez_compressed(fname, a=eigen_leads, b=trans)
    print(eigen_leads.flags)
    print(trans.flags)
    data = np.load(fname)
    np.dot(data['a'], data['b'])  # <-- fails here
    K = np.dot(eigen_leads, trans)   # <-- used to fail here before I added the above lines

Entonces, al menos nada se pierde en el extremo de Azure debido a los pasos np.savez / np.load .

Estoy intentando correr con OPENBLAS_CORETYPE: 'nehalem' para ver si ayuda.

Entonces, ¿tal vez haya dos errores diferentes aquí?

Además, configurar OPENBLAS_VERBOSE: 2 no parece tener ningún efecto, no estoy seguro de por qué

Después de configurar detallado, agregue un comando

python -c "importar numpy"

Pytest probablemente se esté comiendo esto, supongo.

El jueves 23 de julio de 2020 a las 19:04, Eric Larson [email protected] escribió:

Además, configurar OPENBLAS_VERBOSE: 2 no parece tener ningún efecto, no
seguro por qué

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

Este comando localmente incluso no me da ningún resultado detallado:

OPENBLAS_VERBOSE=2 python -c "import numpy as np, glob; data = np.load(glob.glob('bad/*.npz')[0]); a, b = data['a'], data['b']; print(np.dot(a, b).shape)"

Pero tal vez mi sistema OpenBLAS sea demasiado antiguo. Enviaré un compromiso a Azure para que lo ejecute solo después de que falle.

Parece que OPENBLAS_VERBOSE en Azure dice "Core: Haswell". Sin embargo, no sé si eso es correcto o no.

Informé el error en https://github.com/xianyi/OpenBLAS/issues/2732 y sugirieron que podría arreglarse en el maestro, consulte https://github.com/xianyi/OpenBLAS/issues/2728 . Sin embargo, no tengo idea de la mejor manera de probar esto.

@mattip ¿Sabemos que esto está cerrado por MacPython / openblas-libs # 35? ¿No tenemos que esperar hasta que salga la próxima semana?

@charris Creo que este problema aún está abierto y es probable que se necesite un backport.

¿Podría alguien con un reproductor intentar construir numpy con este compromiso para obtener los últimos binarios de OpenBLAS? Entonces algo como (mabe con errores tipográficos)

git add remote mattip https://github.com/mattip/numpy.git
git fetch mattip  issue-16913
git checkout issue-16913
python tools/openblas_support.py
# copy the output openblas.a to a local directory and make sure numpy uses it
mkdir openblas
copy /path/to/openblas.a openblas
set OPENBLAS=openblas
python -c "from tools import openblas_support; openblas_support.make_init('numpy')"
pip install --no-build-isolation --no-use-pep517 .

Debería haber instalado gfortran con choco install -y mingw si aún no lo ha hecho

... esto es para windows

Debería haber instalado gfortran con choco install -y mingw si aún no lo ha hecho

¿Es esto solo necesario para 32 bits?

https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml#L29 -L31

Intentaré lo que sugieres anteriormente con un choco install -y mingw una vez que averigüe cuál es el /path/to/openblas.a , presumiblemente al ejecutar tools/openblas_support.py (?).

Sí, python tools/openblas_support.py imprime dónde encontrar openblas.a

Necesitas gfortran. Las máquinas azure tienen instalado mingw de 64 bits. Si tiene 32 bits, la invocación es un poco diferente. También debe configurar -m32 (pero solo para 32 bits).

Acabo de copiar literalmente la mayor parte de https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml usando master branch de NumPy para reproducir primero el error, y tuve éxito en tener segfault .

Luego cambié a mattip/issue-16913 y falla con un error de descarga de URL para:

https://anaconda.org/multibuild-wheels-staging/openblas-libs/v0.3.9-452-g349b722d/download/openblas-v0.3.9-452-g349b722d-win_amd64-gcc_7_1_0.zip

... parece que no hay OpenBLAS de 32 bits para Windows de 64 bits en:

https://anaconda.org/multibuild-wheels-staging/openblas-libs/files

Supongo que podría agregar la etiqueta para que use OpenBLAS de 64 bits.

2 están ahí y 1 todavía se está construyendo. Debería estar listo en una hora.

Mientras tanto agregué:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

Y se construyó muy bien. ¡Ya no segfaults ! Lo volveré a ejecutar unas cuantas veces solo para estar seguro. No dude en enviarme un ping cuando las librerías OpenBLAS Win64 de 32 bits estén activas y pueda eliminar fácilmente estas líneas y volver a probar.

Cualquier cambio que ejecute el conjunto de pruebas completo :-)

python -c "import numpy; numpy.test('full')"

Parece que los de 32 bits están activos, y eso también funciona .

Voy a probar el conjunto de pruebas completo ahora

Obtiene un extraño error de recolección de prueba que involucra f2py :

https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=8372&view=logs&j=a846d25a-e32c-5640-1b53-e815fab94407&t=14a4ea33-5055-5caa-db84-413553e060fb

No debería perder más tiempo en este otro tema. Puedo esperar hasta la próxima semana y probar el semanario que, con suerte, tendrá BLAS.

Tenga en cuenta que podemos ejecutar las compilaciones nocturnas en cualquier momento enviando una confirmación a la rama maestra.

Ok, esperaré hasta ver uno nuevo para ver si el problema con Windows 10 2004 está solucionado.

@bashtage ¿ Alguna actualización sobre esto?

OpenBLAS todavía está roto en la versión más reciente de Windows. Es muy poco estándar incluso obtener buena información de depuración debido a la combinación de la cadena de herramientas, al menos para mí.