Numpy: numpy1.19.0を使用したAzureCI（Windowsインスタンス）でのエラー

それは一貫して失敗しますか、それともたまにしか失敗しませんか？ ローカルマシンでプロジェクトをビルドしようとするWindows開発者はいますか？

こんにちは、
ありがとう！

一貫して何度も失敗しました。その時点で、Azure開発者に質問することを考えました（最初の推測では、VMのセットアップで何かが変更された可能性があります）。

このリンクには、問題が厄介である可能性があることを発見したMicrosoft開発者との話し合いがあります： https ：

残念ながら、ローカルのWindowsマシンでプロジェクトをビルドできる人は誰もいません:(

次に、再現するための明確な一連の手順が必要になります

azure-pipelines.ymlは機能しますか？

これが私たちが使用しているものです（https://github.com/equinor/pylops/blob/master/azure-pipelines.yml）現時点でコメントアウトされています... Python3.7を使用したかなり標準的なセットアップであることがわかります、requirements-dev.txtファイル（https://github.com/equinor/pylops/blob/master/requirements-dev.txt）に依存関係をインストールしてから、テストを実行します。

すでに述べたように、これをコメントアウトしてnumpy 1.18.5を強制的に実行すると、新しい1.19が壊れたように見えます

Azureで実行されているイメージのWindowsバージョンのメジャーバージョンとマイナーバージョンは何ですか？ つまり、 systeminfoはOS Version何を出力しますか？

Azureパイプラインで使用されているAzureVMの詳細については、 https ： ＆tabs = yamlおよびへのリンクを参照してhttps://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Azureパイプラインでsysteminfoを実行する方法がわかりません、何か提案はありますか？

コマンドラインから実行され、出力をターミナルにダンプするため、コマンドとして実行に追加できます。

CIで実行されるPRでこれを実行して、その内容を確認できます。 WindowsとpipNumPyの19041ビルドに問題があったので、私は尋ねています。

答えは2番目のリンクにありました：

OSバージョン：10.0.17763ビルド1282

だから私の考えは実を結ばない。

Windows用の最新のピップホイールにいくつかの問題があることを知っているとあなたは言います、それはおそらくそれに関連していますか？

これは実際には（おそらく）19041年に導入されたWindowsのバグです。しかし、あなたははるかに古いバージョンを使用しているので、これは問題ではありません。

Conda NumPyには影響せず、WindowsとOpenBlasに問題があると思われるため、PipNumPyのみに影響します。

なるほど：）1.9.1がリリースされたというメールを受け取りました。 Azureパイプラインを再トリガーして、最新バージョンをインストールし、それが機能するかどうかを確認します。

残念ながら、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 :(

OpenBlasのバグ。

これが再現例です：

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

シンボルなしのデバッグ情報は次のとおりです。

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

バグをトリガーするには、配列をかなり大きくする必要があることに注意してください（10kパス、12kパスではありません）。

クイックチェック：

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

合格しますが、デフォルトのカーネル（ Zen ）、およびHaswellとSandybridge両方に、アクセス違反があります。

たぶん、新しいOpenBLAS0.3.10を使用するnumpyHEADも失敗することを確認する価値があります。 または多分あなたはすでにしましたか？

@mattipいいえ私はまだこれを試していません。 pip install git+https://github.com/numpy/numpyマスターから直接でこぼこをインストールすることを意味しますか？ 私はそれを試してみることができます:)

そしてあなたの質問に@bashtage （失敗したテストはnumbaをまったく使用しますか？numba 0.50は、使用できない組み込み関数を誤って使用するWindowsの一部のバージョンにバグがあります。これにより、別のプロジェクトでクラッシュが発生しました。）電子メールですが、このスレッドでは表示されないようです...クラッシュするテストでは、 numpyとpyfftw両方の操作が使用されます。 この突然のメッセージでクラッシュするため、実際にクラッシュする行を特定するのは困難です。 しかし、 pyfftwはnumbaをまったく使用していないと思います。少なくとも、依存関係の1つではありません。

NumPyのHEADをGitHubリポジトリから直接インストールしようとしましたが、Windowsビルドは完了するまで実行されます-突然のクラッシュはありません： https ：

興味深いことに、依存関係としてNumPyを持っている一部のライブラリは正しくインストールされていないようで（理由はわかりません）、一部のテストはすべてのOSで失敗しますが、少なくとも以前のように完全にクラッシュするわけではありません...

毎晩使用してもエラーはありません：

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

GitHubリポジトリから直接NumPyのHEADをインストールしてみました

明示的にビルドしない限り、これにはOpenBLASがありません。デフォルトでは、 pip install git+https://github.com/numpy/numpy.git低速で汎用的なBLASが得られます。

OpenBLASを1.19.2にアップグレードしたいようですので、これをマークします。

Azureの最新の--preビルド（numpy-1.20.0.dev0 + a0028bc）でも同じ問題が発生している可能性があると思います：

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

問題の行は次のとおりです。

K = np.dot(eigen_leads, trans)

それが役立つ場合は、配列をディスクに保存し、Azureアーティファクトを介してそれらを取得してみてください。

それはそれのように見えます。 あなたは私が正しく働いていたのと同じプレを使用しています。

追加することをお勧めします

$env:OPENBLAS_VERBOSE=2

または

set OPENBLAS_VERBOSE=2

テンプレートにアクセスして、使用されているカーネルを確認します。

それが役立つ場合は、配列をディスクに保存し、Azureアーティファクトを介してそれらを取得してみてください。

dtypesとdimensionsを知っていればおそらく十分でしょう。

さて、乗算されている行列を書き込み、アーティファクトをアップロードするnumpy + scipy + matplotlib + pytest（およびdeps）だけを使用して、失敗したテストを1回実行するだけで再現できます。これは、アーティファクトタブです。

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

最後の.npzは、失敗したもの（27 MB）である必要があります。 ローカルではLinuxでは問題ありません。

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

OPENBLAS_VERBOSE機能させるために取り組んでいますが、実際に渡される出力をキャプチャしないためにpytest -sを使用するたびにそうです。 これは偶然かもしれませんが、私たちは見るでしょう...

おかしい、私は今上記の再生機でもそれを見ています。

OPENBLAS_CORETYPEをPrescottまたはNehalemに設定した場合、表示されません。 Zen、Sandybridge、Haswellで見ています。

Windowsでnpzのデータを使用してローカルで再現することはできません。

Windowsでnpzのデータを使用してローカルで再現することはできません。

Azure上のFWIWは、ここで実行されたコードの最後から2番目の行で失敗するため、save-load-round-tripedデータを使用して再現できます。

    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

したがって、 np.savez / np.loadステップが原因で、Azure側で少なくとも何も失われません。

ただし、 OPENBLAS_CORETYPE: 'nehalem'して、役立つかどうかを確認しようとしています。

では、実際にはここに2つの異なるバグがあるのでしょうか。

また、 OPENBLAS_VERBOSE: 2設定しても効果がないようですが、理由はわかりません

詳細を設定した後、コマンドを追加します

python -c "import numpy"

Pytestはおそらくこれを食べていると思います。

木、2020年7月23日には、午前19時04エリック・ラーソンの[email protected]は書きました：

また、OPENBLAS_VERBOSE：2を設定しても効果はないようですが、
確かに理由

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 、または
退会
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
。

このコマンドはローカルでも詳細な出力を提供しません。

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

しかし、おそらく私のシステムOpenBLASは古すぎます。 Azureにコミットをプッシュして、失敗した後にこれを単独で実行できるようにします。

AzureのOPENBLAS_VERBOSEが「Core：Haswell」と言っているようです。 それが正しいかどうかはわかりませんが。

https://github.com/xianyi/OpenBLAS/issues/2732でエラーを報告しましたが、マスターで修正される可能性があることが示唆されましたください。 ただし、これをテストするための最良の方法はわかりません。

@mattipこれがMacPython / openblas-libs＃35によって閉じられていることを知っていますか？ 次の週が終わるまで待つ必要はありませんか？

@charrisこの問題はまだ開いていると思いますが、バックポートが必要になる可能性があります。

リプロデューサーを持っている人が、このコミットでnumpyを構築して、最新のOpenBLASバイナリを取得しようとすることはできますか？ だから（タイプミスのあるマベ）のようなもの

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 .

まだインストールしていない場合は、 choco install -y mingwを使用してgfortranをインストールする必要があります

...これはWindows用です

まだインストールしていない場合は、choco install -ymingwを使用してgfortranをインストールする必要があります。

これは32ビットにのみ必要ですか？

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

/path/to/openblas.aが何であるかを理解したら、 tools/openblas_support.py （？）を実行して、上記の提案をchoco install -y mingw試してみます。

はい、 python tools/openblas_support.pyはopenblas.a場所を出力します

gfortranが必要です。 Azureマシンにはmingw64ビットがインストールされています。 32ビットの場合、呼び出しは少し異なります。 また、 -m32を設定する必要があります（ただし、32ビットの場合のみ）。

NumPyのmasterブランチを使用してhttps://github.com/numpy/numpy/blob/master/azure-steps-windows.ymlのほとんどを逐語的にコピーし、最初にエラーを再現しました。それはsegfaultです。

次に、 mattip/issue-16913切り替えましたが、次のURLダウンロードエラー

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

...次の場所には64ビットWindows用の32ビットOpenBLASがないようです。

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

タグを追加して64ビットのOpenBLASを使用できると思いますか？

2つがあり、1つはまだ構築中です。 1時間以内に起動する必要があります。

その間に私は追加しました：

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

そしてそれはうまく構築されました。 セグメンテーション違反はなくなりました！ 念のため、何度か再実行します。 32ビットのOpenBLASWin64ライブラリが起動したら、遠慮なくpingを送信してください。これらの行を簡単に削除して、再テストできます。

完全なテストスイートを実行する変更:-)

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

32ビットのものが稼働しているように見えますが、それも機能します。

今すぐ完全なテストスイートを実行します

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

この他の問題にこれ以上時間を無駄にしないでください-私は来週まで待って、うまくいけばBLASを持っている毎週テストすることができます。

マスターブランチにコミットをプッシュすることで、いつでもナイトリービルドを実行できることに注意してください。

OK、新しいものが表示されるまで待って、Windows 102004の問題が修正されているかどうかを確認します。

@bashtageこれに関する更新はありますか？

OpenBLASは、Windowsの最新リリースではまだ壊れています。 少なくとも私にとっては、ツールチェーンが混在しているため、適切なデバッグ情報を取得することさえ非常に非標準です。