Numpy: Kesalahan pada Azure CI (contoh Windows) dengan numpy 1.19.0

Apakah gagal secara konsisten atau hanya sesekali? Apakah Anda memiliki pengembang windows yang dapat mencoba membangun proyek di komputer lokal?

Hai,
Terima kasih!

Itu gagal secara konsisten berkali-kali .. pada saat itu saya berpikir untuk bertanya kepada pengembang Azure (perkiraan awal saya adalah mungkin ada sesuatu yang berubah dalam pengaturan VM mereka).

Tautan ini berisi diskusi yang saya lakukan dengan pengembang Microsoft yang melihat masalahnya bisa jadi numpy: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comment -1119179

Sayangnya saya tidak memiliki siapa pun yang dapat mencoba membangun proyek di mesin windows lokal :(

Kemudian kita akan membutuhkan serangkaian langkah yang jelas untuk mereproduksi

Akankah azure-pipelines.yml berfungsi?

Inilah yang kami gunakan (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml) yang dikomentari saat ini ... Anda dapat melihat bahwa ini adalah pengaturan yang cukup standar, menggunakan Python 3.7 , menginstal dependensi di file requirement-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) dan kemudian menjalankan pengujian.

Seperti yang sudah saya sebutkan, jika saya mengomentari ini dan memaksa numpy 1,18.5 semuanya berjalan, sepertinya itu adalah 1,19 baru untuk ditembus

Apa gambar versi windows versi mayor dan minor yang berjalan di Azure? yaitu, apa yang dicetak systeminfo untuk OS Version ?

Saya dapat menemukan detail VM Azure yang digunakan di Azure Pipelines di sini: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml dan tautan ke perangkat lunak yang diinstal https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Saya tidak yakin bagaimana menjalankan systeminfo pada pipeline Azure, ada saran?

Ini berjalan dari baris perintah dan membuang output ke terminal, sehingga Anda dapat menambahkannya ke proses Anda sebagai perintah.

Anda bisa melakukan ini di PR yang berjalan di CI untuk melihat apa yang dikatakannya. Saya bertanya karena ada masalah dengan versi 19041 Windows dan pip NumPy.

Jawabannya ada di tautan kedua:

Versi OS: 10.0.17763 Build 1282

Jadi ide saya tidak membuahkan hasil.

Anda bilang Anda tahu ada beberapa masalah dengan roda pip terbaru untuk Windows, apakah mungkin terhubung dengan itu?

Ini sebenarnya (mungkin) bug Windows yang diperkenalkan pada tahun 19041. Tetapi Anda menggunakan versi yang jauh lebih lama jadi ini bukan masalahnya.

Itu tidak mempengaruhi Conda NumPy, hanya pip NumPy karena tampaknya ada masalah dengan Windows dan OpenBlas.

Saya mengerti :) Saya mendapat email bahwa 1.9.1 telah dirilis. Saya akan mencoba memicu kembali pipeline Azure yang sekarang akan menginstal versi terbaru dan melihat apakah itu berfungsi, akan memberi tahu Anda

Sayangnya masih gagal dengan 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-fb76b-b46 :(

Bug di OpenBlas.

Berikut adalah contoh reproduksi:

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

Informasi debug tanpa simbol adalah:

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

Perhatikan bahwa array harus cukup besar (10k lintasan, 12k tidak) untuk memicu bug.

Pemeriksaan cepat:

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

lolos tetapi kernel default ( Zen ), serta Haswell dan Sandybridge , keduanya memiliki pelanggaran akses.

Mungkin perlu dicek bahwa HEAD numpy, yang menggunakan OpenBLAS 0.3.10 yang lebih baru, juga gagal. Atau mungkin Anda sudah melakukannya?

@ mattip no Saya belum mencoba ini. Maksud Anda menginstal bergelombang langsung dari master dengan pip install git+https://github.com/numpy/numpy ? Saya bisa mencobanya :)

Dan untuk pertanyaan Anda @bashtage (Apakah tes yang gagal menggunakan numba sama sekali? Numba 0.50 memiliki bug di beberapa versi windows yang salah menggunakan intrinsik yang tidak tersedia. Hal ini menyebabkan crash untuk saya di proyek lain.) Yang saya dapatkan melalui email tetapi tidak bisa melihat di utas ini ... pengujian yang macet menggunakan operasi numpy dan pyfftw . Karena crash dengan pesan yang tiba-tiba ini, sulit untuk mengatakan di baris mana dia benar-benar crash. Tetapi saya tidak berpikir pyfftw sama sekali tidak menggunakan numba, setidaknya itu bukan salah satu dependensinya

Saya baru saja mencoba dengan Menginstal KEPALA NumPy langsung dari repositori GitHub dan windows build berjalan sampai selesai - tidak ada crash mendadak: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Menariknya beberapa perpustakaan yang memiliki ketergantungan NumPy tampaknya tidak terpasang dengan benar (tidak yakin mengapa) dan beberapa tes gagal untuk semua OS, tetapi setidaknya itu bukan crash lengkap seperti sebelumnya ...

Tidak ada kesalahan menggunakan nightly:

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

Saya baru saja mencoba Menginstal KEPALA NumPy langsung dari repositori GitHub

Ini tidak memiliki OpenBLAS kecuali Anda secara eksplisit membangunnya. Secara default Anda mendapatkan BLAS generik yang lambat dengan pip install git+https://github.com/numpy/numpy.git .

Sepertinya kami ingin mengupgrade OpenBLAS untuk 1.19.2, jadi tandai ini.

Saya rasa saya mungkin mengalami masalah yang sama pada --pre build (numpy-1.20.0.dev0 + a0028bc) terbaru di 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

Baris yang dimaksud hanyalah:

K = np.dot(eigen_leads, trans)

Jika membantu, saya dapat mencoba menyimpan array ke disk dan mengeluarkannya melalui artefak Azure.

Sepertinya begitu. Anda menggunakan pra yang sama dengan yang saya gunakan dengan benar.

Anda mungkin ingin menambahkan

$env:OPENBLAS_VERBOSE=2

atau

set OPENBLAS_VERBOSE=2

ke template Anda untuk mengetahui kernel mana yang sedang digunakan.

Jika membantu, saya dapat mencoba menyimpan array ke disk dan mengeluarkannya melalui artefak Azure.

Mungkin cukup mengetahui jenis dan dimensinya.

Oke, direproduksi dalam satu kali pengujian yang gagal hanya dengan numpy + scipy + matplotlib + pytest (dan deps) yang menulis matriks yang dikalikan dan kemudian mengunggah artefak, berikut adalah tab artefak:

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

.npz harus menjadi yang gagal (27 MB). Secara lokal di Linux itu baik-baik saja:

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

Bekerja untuk mendapatkan OPENBLAS_VERBOSE bekerja tetapi sepertinya setiap kali saya menggunakan pytest -s untuk tidak menangkap output yang benar-benar lewat. Ini mungkin hanya kebetulan, kita akan lihat ...

Lucu, saya juga melihatnya dengan alat reproduksi di atas sekarang.

Saya tidak melihatnya jika saya menyetel OPENBLAS_CORETYPE ke Prescott atau Nehalem. Saya melihatnya dengan Zen, Sandybridge dan Haswell.

Saya tidak dapat mereproduksi secara lokal menggunakan data dari npz Anda di Windows.

Saya tidak dapat mereproduksi secara lokal menggunakan data dari npz Anda di Windows.

FWIW di Azure saya dapat mereproduksinya dengan data save-load-round-tripped, karena sekarang gagal pada baris kedua hingga terakhir dalam kode yang dieksekusi di sini:

    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

Jadi setidaknya tidak ada yang hilang di ujung Azure karena langkah np.savez / np.load .

Saya mencoba lari dengan OPENBLAS_CORETYPE: 'nehalem' untuk melihat apakah membantu.

Jadi mungkin sebenarnya ada dua bug berbeda di sini?

Selain itu, menyetel OPENBLAS_VERBOSE: 2 tampaknya tidak memiliki efek apa pun, tidak yakin mengapa

Setelah mengatur verbose tambahkan perintah

python -c "import numpy"

Kurasa Pytest mungkin memakan ini.

Pada Kamis, 23 Juli 2020, 19:04 Eric Larson [email protected] menulis:

Selain itu, menyetel OPENBLAS_VERBOSE: 2 sepertinya tidak berpengaruh apa-apa
yakin kenapa

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

Perintah ini secara lokal bahkan tidak memberi saya keluaran verbose:

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

Tapi mungkin OpenBLAS sistem saya terlalu tua. Saya akan mendorong komitmen ke Azure untuk membuatnya menjalankan ini dengan sendirinya setelah gagal.

Sepertinya OPENBLAS_VERBOSE di Azure bertuliskan "Core: Haswell". Saya tidak tahu apakah itu benar atau tidak.

Saya melaporkan kesalahan di https://github.com/xianyi/OpenBLAS/issues/2732 dan mereka menyarankan itu mungkin diperbaiki di master, lihat https://github.com/xianyi/OpenBLAS/issues/2728 . Tidak ada ide cara terbaik untuk menguji ini.

@ Mattip Apakah kita tahu ini ditutup oleh MacPython / openblas-libs # 35? Bukankah kita perlu menunggu sampai mingguan berikutnya habis?

@charris Saya pikir masalah ini masih terbuka, dan kemungkinan besar akan dibutuhkan backport.

Bisakah seseorang dengan reproduser mencoba membuat numpy dengan commit ini untuk mendapatkan binari OpenBLAS terbaru? Jadi sesuatu seperti (mabe dengan kesalahan ketik)

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 .

Anda harus menginstal gfortran dengan choco install -y mingw jika Anda belum melakukannya

... ini untuk windows

Anda harus menginstal gfortran dengan choco install -y mingw jika Anda belum melakukannya

Apakah ini hanya diperlukan untuk 32-bit?

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

Saya akan mencoba apa yang Anda sarankan di atas dengan choco install -y mingw setelah saya mengetahui apa /path/to/openblas.a itu - mungkin dari menjalankan tools/openblas_support.py (?).

Ya, python tools/openblas_support.py mencetak di mana menemukan openblas.a

Anda membutuhkan gfortran. Mesin biru memiliki mingw 64-bit terpasang. Jika Anda 32-bit, pemanggilannya sedikit berbeda. Anda juga perlu menyetel -m32 (tetapi hanya untuk 32-bit).

Saya baru saja menyalin sebagian besar https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml menggunakan master cabang NumPy untuk pertama kali mereproduksi kesalahan, dan berhasil memiliki itu segfault .

Saya kemudian beralih ke mattip/issue-16913 dan gagal dengan kesalahan pengunduhan URL untuk:

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

... sepertinya tidak ada OpenBLAS 32-bit untuk Windows 64-bit di:

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

Saya kira saya bisa menambahkan tag untuk mendapatkannya menggunakan OpenBLAS 64-bit?

2 ada dan 1 masih dibangun. Seharusnya dalam satu jam.

Sementara itu saya menambahkan:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

Dan itu dibangun dengan baik. Tidak ada lagi segfault ! Saya akan menjalankannya ulang beberapa kali hanya untuk memastikan. Jangan ragu untuk melakukan ping kepada saya ketika OpenBLAS Win64 libs 32-bit sudah aktif dan saya dapat dengan mudah menghapus baris ini dan menguji ulang.

Setiap perubahan yang Anda jalankan rangkaian pengujian lengkap :-)

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

Sepertinya yang 32 bit sudah habis, dan itu juga berfungsi .

Saya akan mencoba rangkaian pengujian lengkap sekarang

Itu mendapat kesalahan pengumpulan tes aneh yang melibatkan 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

Anda tidak perlu membuang waktu lagi untuk masalah lain ini - saya bisa menunggu sampai minggu depan dan menguji mingguan yang diharapkan memiliki BLAS.

Perhatikan bahwa kita bisa menjalankan nightly build kapan saja dengan mendorong komit ke cabang master.

Oke, saya akan menunggu hingga saya melihat yang baru untuk melihat apakah masalah dengan Windows 10 2004 sudah diperbaiki.

@bashtage Ada pembaruan tentang ini?

OpenBLAS masih rusak pada rilis terbaru Windows. Sangat tidak standar bahkan untuk mendapatkan informasi debugging yang baik karena rantai campuran ke alat, setidaknya untuk saya.