Numpy: Fehler in Azure CI (Windows-Instanz) mit numpy 1.19.0

Scheitert es konsequent oder nur ab und zu? Haben Sie Windows-Entwickler, die versuchen können, das Projekt auf einem lokalen Computer zu erstellen?

Hallo,
Vielen Dank!

Es schlug viele Male durchgehend fehl. Zu diesem Zeitpunkt dachte ich darüber nach, Azure-Entwickler zu fragen (meine anfängliche Vermutung war, dass sich möglicherweise etwas an der Einrichtung ihrer VMs geändert hatte).

Dieser Link hat die Diskussion, die ich mit einem Microsoft-Entwickler geführt habe, der das Problem entdeckt hat, könnte numpy gewesen sein: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comment -1119179

Leider habe ich niemanden, der versuchen kann, das Projekt auf einem lokalen Windows-Computer zu erstellen :(

Dann brauchen wir klare Schritte, um zu reproduzieren

Würde die Datei azure-pipelines.yml funktionieren?

Folgendes verwenden wir (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml), das im Moment auskommentiert wurde ... Sie können sehen, dass es sich um ein ziemlich standardmäßiges Setup handelt, das Python 3.7 verwendet Installieren von Abhängigkeiten in der Datei "resources-dev.txt" (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) und Ausführen der Tests.

Wie ich bereits erwähnt habe, wenn ich dies auskommentiere und numpy 1.18.5 erzwinge, scheint alles zu laufen, scheint es die neue 1.19 zu sein, die zu brechen ist

Was ist die Haupt- und Nebenversion der Windows-Version des Images, das unter Azure ausgeführt wird? dh was druckt systeminfo für OS Version ?

Die Details zu den in Azure-Pipelines verwendeten Azure-VMs finden Sie hier: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml und den Link zu installierte Software https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Ich bin nicht sicher, wie systeminfo in einer Azure-Pipeline ausgeführt werden soll.

Es wird über die Befehlszeile ausgeführt und gibt die Ausgabe an das Terminal aus, sodass Sie sie als Befehl zu Ihrem Lauf hinzufügen können.

Sie können dies in einer PR tun, die auf CI ausgeführt wird, um zu sehen, was darin steht. Ich frage, da es Probleme mit dem 19041-Build von Windows und pip NumPy gab.

Die Antwort war im zweiten Link:

Betriebssystemversion: 10.0.17763 Build 1282

Meine Idee trägt also keine Früchte.

Sie sagen, Sie wissen, dass es einige Probleme mit den neuesten Pip-Rädern für Windows gibt. Ist dies wahrscheinlich damit verbunden?

Es ist tatsächlich (wahrscheinlich) ein Windows-Fehler, der 19041 eingeführt wurde. Sie verwenden jedoch eine viel ältere Version, sodass dies nicht das Problem ist.

Es betrifft nicht Conda NumPy, sondern nur pip NumPy, da es ein Problem mit Windows und OpenBlas zu sein scheint.

Ich verstehe :) Ich habe eine E-Mail erhalten, dass 1.9.1 veröffentlicht wurde. Ich werde versuchen, die Azure-Pipeline erneut auszulösen, die jetzt die neueste Version installiert, und prüfen, ob dies funktioniert

Leider immer noch nicht mit 1.19.1 https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=45&view=logs&j=50448a2f-9550-51a0-b6c4-5ec64224dd81&t=a6a6804f-7af1-5f53-b76b-b46f500d6778 :(

Ein Fehler in OpenBlas.

Hier ist ein Reproduktionsbeispiel:

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

Die Debugging-Informationen ohne Symbole lauten:

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

Beachten Sie, dass das Array ziemlich groß sein muss (10.000 Durchgänge, 12.000 nicht), um den Fehler auszulösen.

Schneller Check:

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

Besteht, aber der Standardkernel ( Zen ) sowie Haswell und Sandybridge haben beide Zugriffsverletzungen.

Vielleicht lohnt es sich zu überprüfen, ob der numpy HEAD, der ein neueres OpenBLAS 0.3.10 verwendet, ebenfalls fehlschlägt. Oder hast du es vielleicht schon getan?

@mattip nein ich hatte das noch nicht ausprobiert. Sie meinen, holprige Installation direkt vom Master mit pip install git+https://github.com/numpy/numpy ? Ich kann es versuchen :)

Und zu Ihrer Frage @bashtage ( numpy als auch pyfftw Operationen. Da es mit dieser plötzlichen Meldung abstürzt, ist es schwer zu sagen, an welcher Linie es wirklich abstürzt. Aber ich glaube nicht, dass pyfftw numba verwendet, zumindest ist es keine ihrer Abhängigkeiten

Ich habe gerade versucht, den HEAD of NumPy direkt aus dem GitHub-Repository zu installieren, und der Windows-Build läuft bis zum Abschluss - kein plötzlicher Absturz: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Interessanterweise scheinen einige Bibliotheken mit NumPy als Abhängigkeit nicht richtig zu installieren (nicht sicher warum) und einige Tests schlagen für alle Betriebssysteme fehl, aber zumindest ist es kein vollständiger Absturz wie zuvor ...

Kein Fehler bei der nächtlichen Verwendung:

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

Ich habe gerade versucht, den HEAD of NumPy direkt aus dem GitHub-Repository zu installieren

OpenBLAS ist nur verfügbar, wenn Sie es explizit einbauen. Standardmäßig erhalten Sie ein langsames, generisches BLAS mit einem pip install git+https://github.com/numpy/numpy.git .

Es sieht so aus, als ob wir OpenBLAS für 1.19.2 aktualisieren möchten.

Ich glaube, ich habe möglicherweise das gleiche Problem beim letzten Build von --pre (numpy-1.20.0.dev0 + a0028bc) in 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

Die fragliche Zeile lautet nur:

K = np.dot(eigen_leads, trans)

Wenn es hilft, könnte ich versuchen, die Arrays auf der Festplatte zu speichern und über ein Azure-Artefakt herauszuholen.

Das sieht so aus. Sie verwenden das gleiche Pre, mit dem ich richtig gearbeitet habe.

Vielleicht möchten Sie hinzufügen

$env:OPENBLAS_VERBOSE=2

oder

set OPENBLAS_VERBOSE=2

zu Ihrer Vorlage, um zu wissen, welcher Kernel verwendet wird.

Wenn es hilft, könnte ich versuchen, die Arrays auf der Festplatte zu speichern und über ein Azure-Artefakt herauszuholen.

Es würde wahrscheinlich ausreichen, die d-Typen und Dimensionen zu kennen.

Okay, reproduziert in einem einzigen Durchlauf des fehlgeschlagenen Tests mit nur numpy + scipy + matplotlib + pytest (und deps), der die zu multiplizierenden Matrizen schreibt und dann die Artefakte hochlädt. Hier ist die Registerkarte Artefakte:

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

Das letzte .npz sollte das fehlerhafte sein (27 MB). Lokal unter Linux ist alles in Ordnung:

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

Ich arbeite daran, die OPENBLAS_VERBOSE Laufen zu bringen, aber es scheint, als würde ich jedes Mal, wenn ich pytest -s , die tatsächlich übergebene Ausgabe nicht erfassen. Dies könnte jedoch nur ein Zufall sein, wir werden sehen ...

Komisch, ich sehe es jetzt auch mit dem Wiedergabegerät oben.

Ich sehe es nicht, wenn ich OPENBLAS_CORETYPE auf Prescott oder Nehalem setze. Ich sehe es bei Zen, Sandybridge und Haswell.

Ich kann nicht lokal mit den Daten von Ihrem npz unter Windows reproduzieren.

Ich kann nicht lokal mit den Daten von Ihrem npz unter Windows reproduzieren.

FWIW unter Azure Ich kann es mit den Daten zum Speichern, Laden und Auslösen reproduzieren, da es jetzt in der vorletzten Zeile des ausgeführten Codes hier fehlschlägt:

    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

Zumindest geht am Azure-Ende aufgrund der Schritte np.savez / np.load nichts verloren.

Ich versuche einen Lauf mit OPENBLAS_CORETYPE: 'nehalem' zu sehen, ob es hilft.

Vielleicht gibt es hier tatsächlich zwei verschiedene Fehler?

Außerdem scheint das Setzen von OPENBLAS_VERBOSE: 2 keine Auswirkungen zu haben, nicht sicher warum

Fügen Sie nach dem Einstellen von verbose einen Befehl hinzu

python -c "import numpy"

Pytest isst das wahrscheinlich, würde ich vermuten.

Am Do, 23. Juli 2020, 19:04 schrieb Eric Larson [email protected] :

Auch das Setzen von OPENBLAS_VERBOSE: 2 scheint keine Auswirkung zu haben, nicht
sicher warum

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

Dieser Befehl vor Ort gibt mir sogar keine ausführliche Ausgabe:

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

Aber vielleicht ist mein System OpenBLAS zu alt. Ich werde ein Commit an Azure senden, damit es dieses selbst ausführt, nachdem es fehlgeschlagen ist.

OPENBLAS_VERBOSE in Azure sagt anscheinend "Core: Haswell". Ich weiß allerdings nicht, ob das richtig ist oder nicht.

Ich habe den Fehler in https://github.com/xianyi/OpenBLAS/issues/2732 gemeldet und sie haben vorgeschlagen, dass er möglicherweise im Master behoben wird (siehe https://github.com/xianyi/OpenBLAS/issues/2728) . Keine Ahnung, wie man das am besten testen kann.

@mattip Wissen wir, dass dies von MacPython / openblas-libs # 35 geschlossen wird? Müssen wir nicht warten, bis die nächste Woche vorbei ist?

@charris Ich denke, dieses Problem ist noch offen und ein Backport wird wahrscheinlich benötigt.

Könnte jemand mit einem Reproducer versuchen, mit diesem Commit eine Nummer zu erstellen, um die neuesten OpenBLAS-Binärdateien zu erhalten? Also so etwas wie (Mabe mit Tippfehlern)

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 .

Sie sollten gfortran mit choco install -y mingw installieren, falls Sie dies noch nicht getan haben

... das ist für Windows

Sie sollten gfortran mit choco install -y mingw installieren, falls Sie dies noch nicht getan haben

Ist dies nur für 32-Bit erforderlich?

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

Ich werde versuchen, was Sie oben mit einem choco install -y mingw vorschlagen, sobald ich herausgefunden habe, was das /path/to/openblas.a ist - vermutlich durch Ausführen von tools/openblas_support.py (?).

Ja, python tools/openblas_support.py druckt aus, wo openblas.a

Du brauchst Gfortran. Auf den Azure-Computern ist mingw 64-Bit installiert. Wenn Sie 32-Bit sind, ist der Aufruf etwas anders. Sie müssen auch -m32 festlegen (jedoch nur für 32-Bit).

Ich habe nur wörtlich den größten Teil von https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml mit dem Zweig master von NumPy kopiert, um den Fehler zuerst zu reproduzieren, und war erfolgreich dabei es segfault .

Ich habe dann zu mattip/issue-16913 gewechselt und es schlägt mit einem URL-Download-Fehler

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

... sieht so aus, als gäbe es kein 32-Bit-OpenBLAS für 64-Bit-Windows in:

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

Ich denke, ich könnte das Tag hinzufügen, damit es 64-Bit-OpenBLAS verwendet.

2 sind da und 1 wird noch gebaut. Sollte innerhalb einer Stunde auf sein.

In der Zwischenzeit habe ich hinzugefügt:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

Und es hat gut gebaut. Keine Segfaults mehr ! Ich werde es ein paar Mal wiederholen, nur um sicherzugehen. Sie können mich gerne anpingen, wenn die 32-Bit-OpenBLAS Win64-Bibliotheken verfügbar sind und ich diese Zeilen problemlos entfernen und erneut testen kann.

Bei jeder Änderung führen Sie die vollständige Testsuite aus :-)

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

Sieht so aus, als wären die 32-Bit-Dateien aktiv, und das funktioniert auch .

Ich werde jetzt die vollständige Testsuite testen

Es wird ein seltsamer Testerfassungsfehler mit 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-413553e060b

Sie sollten keine Zeit mehr mit diesem anderen Thema verschwenden - ich kann bis nächste Woche warten und die Woche testen, die hoffentlich die BLAS haben wird.

Beachten Sie, dass wir die nächtlichen Builds jederzeit ausführen können, indem wir ein Commit an den Hauptzweig senden.

Ok, ich werde warten, bis ich ein neues sehe, um zu sehen, ob das Problem mit Windows 10 2004 behoben ist.

@bashtage Gibt es ein Update dazu?

OpenBLAS ist in der neuesten Version von Windows immer noch defekt. Es ist sehr unüblich, auch nur gute Debugging-Informationen zu erhalten, da die Toolkette gemischt ist, zumindest für mich.