Numpy: Erreur sur Azure CI (instance Windows) avec numpy 1.19.0

Échoue-t-il systématiquement ou seulement de temps en temps? Avez-vous des développeurs Windows qui peuvent essayer de créer le projet sur une machine locale?

Salut,
Merci!

Cela a échoué régulièrement à plusieurs reprises ... à ce moment-là, j'ai pensé à demander aux développeurs Azure (ma première estimation était que peut-être quelque chose avait changé dans la configuration de leurs machines virtuelles).

Ce lien a la discussion que j'ai eue avec un développeur Microsoft qui a repéré le problème aurait pu être numpy: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comment -1119179

Malheureusement, je n'ai personne qui puisse essayer de construire le projet sur une machine Windows locale :(

Ensuite, nous aurons besoin d'un ensemble clair d'étapes pour reproduire

Le fichier azure-pipelines.yml fonctionnerait-il?

Voici ce que nous utilisons (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml) commenté pour le moment ... vous pouvez voir que c'est une configuration assez standard, utilisant Python 3.7 , en installant les dépendances dans le fichier requirements-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) puis en exécutant les tests.

Comme je l'ai déjà mentionné, si je commente cela et que je force numpy 1.18.5 tout fonctionne, il semble que ce soit le nouveau 1.19 à casser

Quelle est la version principale et la version mineure de Windows de l'image exécutée sur Azure? ie, qu'est-ce que systeminfo imprime pour OS Version ?

Je pourrais trouver les détails des machines virtuelles Azure utilisées dans Azure Pipelines ici: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml et le lien vers logiciel installé https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Je ne sais pas comment exécuter systeminfo sur un pipeline Azure, des suggestions?

Il s'exécute à partir de la ligne de commande et vide la sortie sur le terminal, vous pouvez donc l'ajouter à votre exécution en tant que commande.

Vous pouvez le faire dans un PR qui fonctionne sur CI pour voir ce qu'il dit. Je demande car il y a eu des problèmes avec la version 19041 de Windows et pip NumPy.

La réponse était dans le deuxième lien:

Version du système d'exploitation: 10.0.17763 Build 1282

Donc mon idée ne porte aucun fruit.

Vous dites que vous savez qu'il y a des problèmes avec les dernières roues pip pour Windows, est-ce probablement lié à cela?

C'est en fait (probablement) un bogue Windows introduit en 19041. Mais vous êtes sur une version beaucoup plus ancienne donc ce n'est pas le problème.

Cela n'affecte pas Conda NumPy, seulement pip NumPy car il semble y avoir un problème avec Windows et OpenBlas.

Je vois :) J'ai reçu un e-mail indiquant que la version 1.9.1 est sortie. Je vais essayer de redéclencher le pipeline Azure qui installerait maintenant la dernière version et voir si cela fonctionne, vous le fera savoir

Échoue malheureusement toujours avec 1.19.1 https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=45&view=logs&j=50448a2f-9550-51a0-b6c4-5ec64224dd81&t=a6a6804f-7af1-5f46-b76b67b :(

Un bug dans OpenBlas.

Voici un exemple de reproduction:

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

Les informations de débogage sans symboles sont:

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

Notez que le tableau doit être assez grand (10k passes, 12k pas) pour déclencher le bogue.

Vérification rapide:

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

passe mais le noyau par défaut ( Zen ), ainsi que Haswell et Sandybridge , ont tous deux des violations d'accès.

Cela vaut peut-être la peine de vérifier que numpy HEAD, qui utilise un plus récent OpenBLAS 0.3.10, échoue également. Ou peut-être que vous l'avez déjà fait?

@mattip non je n'avais pas encore essayé cela. Vous voulez dire installer Bumpy directement depuis le maître avec pip install git+https://github.com/numpy/numpy ? Je peux essayer :)

Et à votre question @bashtage (Les tests qui échouent utilisent-ils numba? email mais ne semble pas pouvoir voir dans ce fil ... le test qui plante utilise à la fois les opérations numpy et pyfftw . Comme il se bloque avec ce message soudain, il est difficile de dire à quelle ligne il se bloque vraiment. Mais je ne pense pas que pyfftw utilise du tout numba, du moins ce n'est pas une de leurs dépendances

Je viens d'essayer d'installer la tête de NumPy directement à partir du référentiel GitHub et la construction de Windows s'exécute jusqu'à la fin - pas de crash soudain: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Fait intéressant, certaines bibliothèques qui ont NumPy comme dépendance ne semblent pas s'installer correctement (je ne sais pas pourquoi) et certains tests échouent pour tous les systèmes d'exploitation, mais au moins ce n'est pas un crash complet comme avant ...

Aucune erreur lors de l'utilisation nocturne:

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

Je viens d'essayer d'installer la tête de NumPy directement à partir du référentiel GitHub

Cela n'a pas OpenBLAS sauf si vous le construisez explicitement. Par défaut, vous obtenez un BLAS lent et générique avec un pip install git+https://github.com/numpy/numpy.git .

On dirait que nous souhaitons peut-être mettre à jour OpenBLAS pour la version 1.19.2, marquant ainsi ceci.

Je pense que je pourrais rencontrer le même problème sur la dernière version de --pre (numpy-1.20.0.dev0 + a0028bc) sur 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 ligne en question est juste:

K = np.dot(eigen_leads, trans)

Si cela peut vous aider, je pourrais essayer d'enregistrer les baies sur le disque et de les extraire via un artefact Azure.

Ça y ressemble. Vous utilisez le même pré que j'avais fonctionné correctement.

Vous voudrez peut-être ajouter

$env:OPENBLAS_VERBOSE=2

ou

set OPENBLAS_VERBOSE=2

à votre modèle pour savoir quel noyau est utilisé.

Si cela peut vous aider, je pourrais essayer d'enregistrer les baies sur le disque et de les extraire via un artefact Azure.

Il suffirait probablement de connaître les dtypes et les dimensions.

D'accord, reproduit sur une seule exécution du test échoué avec juste numpy + scipy + matplotlib + pytest (et deps) qui écrit les matrices multipliées puis télécharge les artefacts, voici l'onglet des artefacts:

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

Le dernier .npz devrait être le dernier (27 Mo). Localement sur Linux, cela apparaît très 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
)

Travailler à faire fonctionner le OPENBLAS_VERBOSE mais il semble que chaque fois que j'utilise pytest -s pour ne pas capturer la sortie, il passe réellement. Cela pourrait être juste un hasard, cependant, nous verrons ...

Drôle, je le vois aussi avec le reproducteur ci-dessus maintenant.

Je ne le vois pas si je règle OPENBLAS_CORETYPE sur Prescott ou Nehalem. Je le vois avec Zen, Sandybridge et Haswell.

Je ne peux pas reproduire localement en utilisant les données de votre npz sous Windows.

Je ne peux pas reproduire localement en utilisant les données de votre npz sous Windows.

FWIW sur Azure, je peux le reproduire avec les données save-load-round-tripped, car il échoue maintenant sur l'avant-dernière ligne du code exécuté ici:

    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

Donc, au moins, rien n'est perdu à l'extrémité Azure en raison des étapes np.savez / np.load .

J'essaye une course avec OPENBLAS_CORETYPE: 'nehalem' pour voir si cela aide.

Alors peut-être qu'il y a en fait deux bugs différents ici?

De plus, définir OPENBLAS_VERBOSE: 2 ne semble pas avoir d'effet, je ne sais pas pourquoi

Après avoir défini détaillé, ajoutez une commande

python -c "import numpy"

Pytest est probablement en train de manger ça, je suppose.

Le jeu.23 juillet 2020 à 19:04, Eric Larson [email protected] a écrit:

De plus, le réglage OPENBLAS_VERBOSE: 2 ne semble pas avoir d'effet, pas
sûr pourquoi

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

Cette commande localement ne me donne même pas de sortie verbeuse:

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

Mais peut-être que mon système OpenBLAS est trop ancien. Je vais pousser un commit vers Azure pour qu'il s'exécute tout seul après son échec.

On dirait que OPENBLAS_VERBOSE sur Azure indique «Core: Haswell». Je ne sais pas si c'est vrai ou non.

J'ai signalé l'erreur dans https://github.com/xianyi/OpenBLAS/issues/2732 et ils ont suggéré qu'elle pourrait être corrigée dans master, voir https://github.com/xianyi/OpenBLAS/issues/2728 . Aucune idée de la meilleure façon de tester cela, cependant.

@mattip Savons-nous que cela est fermé par MacPython / openblas-libs # 35? N'avons-nous pas besoin d'attendre la sortie de la prochaine semaine?

@charris Je pense que ce problème est toujours ouvert et qu'un backport sera probablement nécessaire.

Quelqu'un avec un reproducteur pourrait-il essayer de construire numpy avec ce commit pour obtenir les derniers binaires OpenBLAS? Donc quelque chose comme (mabe avec des fautes de frappe)

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 .

Vous devriez avoir installé gfortran avec choco install -y mingw si vous ne l'avez pas déjà fait

... c'est pour Windows

Vous devriez avoir installé gfortran avec choco install -y mingw si vous ne l'avez pas déjà fait

Est-ce uniquement requis pour 32 bits?

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

J'essaierai ce que vous suggérez ci-dessus avec un choco install -y mingw une fois que j'aurai compris ce qu'est le /path/to/openblas.a - probablement en exécutant tools/openblas_support.py (?).

Oui, python tools/openblas_support.py imprime où trouver openblas.a

Vous avez besoin de gfortran. Les machines azure ont mingw 64 bits installé. Si vous êtes 32 bits, l'invocation est un peu différente. Vous devez également définir -m32 (mais uniquement pour 32 bits).

Je viens de copier textuellement la plupart de https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml en utilisant master branche de NumPy pour reproduire d'abord l'erreur, et j'ai réussi à avoir il segfault .

Je suis ensuite passé à mattip/issue-16913 et cela échoue avec une erreur de téléchargement d'URL pour:

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

... il semble qu'il n'y ait pas d'OpenBLAS 32 bits pour Windows 64 bits dans:

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

Je suppose que je pourrais ajouter la balise pour qu'elle utilise OpenBLAS 64 bits?

2 sont là et 1 est toujours en construction. Devrait être debout dans l'heure.

En attendant j'ai ajouté:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

Et ça s'est très bien construit. Plus de segfaults ! Je vais le relancer plusieurs fois juste pour être sûr. N'hésitez pas à me cingler lorsque les bibliothèques OpenBLAS Win64 32 bits sont en place et je peux facilement supprimer ces lignes et refaire le test.

Tout changement que vous exécutez la suite de tests complète :-)

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

On dirait que les 32 bits sont en place, et cela fonctionne également .

Je vais lancer la suite de tests complète maintenant

Il obtient une erreur de collecte de tests étrange impliquant 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

Vous ne devriez plus perdre de temps sur cette autre question - je peux attendre la semaine prochaine et tester l'hebdomadaire qui, espérons-le, aura le BLAS.

Notez que nous pouvons exécuter les builds nocturnes à tout moment en poussant un commit dans la branche master.

Ok, j'attendrai de voir un nouveau pour voir si le problème avec Windows 10 2004 est résolu.

@bashtage Une mise à jour à ce sujet?

OpenBLAS est toujours cassé sur la version la plus récente de Windows. Il n'est même pas standard d'obtenir de bonnes informations de débogage à cause de la chaîne d'outils mixte, du moins pour moi.