Numpy: Ошибка в Azure CI (экземпляр Windows) с numpy 1.19.0

Он дает сбой постоянно или только время от времени? Есть ли у вас разработчики Windows, которые могут попытаться собрать проект на локальной машине?

Привет,
благодаря!

Это постоянно терпело неудачу много раз ... в тот момент я подумал о том, чтобы спросить разработчиков Azure (я изначально предполагал, что, возможно, что-то изменилось в их настройке виртуальных машин).

В этой ссылке есть обсуждение, которое я провел с разработчиком Microsoft, который заметил, что проблема могла быть непростой: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comment -1119179

К сожалению, у меня нет никого, кто мог бы попробовать собрать проект на локальной машине с Windows :(

Затем нам понадобится четкий набор шагов для воспроизведения

Будет ли работать azure-pipelines.yml?

Вот что мы используем (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml), закомментированное на данный момент ... вы можете видеть, что это довольно стандартная установка с использованием Python 3.7. , установив зависимости в файле requirements-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt), а затем запустив тесты.

Как я уже упоминал, если я закомментирую это и заставлю numpy 1.18.5, все будет работать, похоже, что это новый 1.19, чтобы сломаться

Какая основная и дополнительная версия образа для Windows работает в Azure? то есть, что systeminfo print для OS Version ?

Подробную информацию о виртуальных машинах Azure, используемых в Azure Pipelines, я мог найти здесь: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml и ссылку на установленное программное обеспечение https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Я не уверен, как запустить systeminfo в конвейере Azure, есть предложения?

Он запускается из командной строки и выгружает вывод в терминал, поэтому вы можете добавить его в свой запуск как команду.

Вы можете сделать это в PR, который работает на CI, чтобы увидеть, что он говорит. Я спрашиваю, потому что были проблемы со сборкой Windows 19041 года и pip NumPy.

Ответ был во второй ссылке:

Версия ОС: 10.0.17763 сборка 1282

Так что моя идея не приносит плодов.

Вы говорите, что знаете, что есть некоторые проблемы с последними версиями pip wheel для Windows, возможно, это связано с этим?

На самом деле (вероятно) это ошибка Windows, появившаяся в 19041 году. Но у вас гораздо более старая версия, так что проблема не в этом.

Это не влияет на Conda NumPy, только на pip NumPy, потому что, похоже, это проблема с Windows и OpenBlas.

Понятно :) Я получил письмо по электронной почте, что версия 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-578b53-b500 :(

Ошибка в 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 имеют нарушения доступа.

Возможно, стоит проверить, что numpy HEAD, который использует более новый OpenBLAS 0.3.10, также не работает. Или, может быть, уже сделали?

@mattip нет, я еще не пробовал. Вы имеете в виду установку bumpy прямо из мастера с помощью pip install git+https://github.com/numpy/numpy ? Я могу попробовать :)

И на ваш вопрос @bashtage ( вообще неудачные тесты numba? Numba 0.50 имеет ошибку в некоторых версиях окон, где он неправильно использует недоступную встроенную функцию. Это вызвало у меня сбои в другом проекте.), Которую я получил через электронной почты, но, похоже, не видит в этом потоке ... тест, который выдает сбой, использует как операции numpy и pyfftw . Поскольку он вылетает из-за этого внезапного сообщения, трудно сказать, на какой строке он действительно вылетает. Но я не думаю, что pyfftw вообще использует numba, по крайней мере, это не одна из их зависимостей

Я просто попытался установить HEAD NumPy непосредственно из репозитория GitHub, и сборка Windows работает до завершения - без внезапного сбоя: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Интересно, что некоторые библиотеки, которые имеют NumPy в качестве зависимости, похоже, не устанавливаются должным образом (не знаю, почему), а некоторые тесты терпят неудачу для всех ОС, но, по крайней мере, это не полный сбой, как раньше ...

Нет ошибок при использовании по ночам:

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

Я просто попробовал установить ГОЛОВУ NumPy прямо из репозитория GitHub

У него нет OpenBLAS, если вы не встроили его явно. По умолчанию вы получаете медленный общий BLAS с pip install git+https://github.com/numpy/numpy.git .

Похоже, мы можем обновить OpenBLAS до версии 1.19.2, поэтому отметьте это.

Я думаю, что могу столкнуться с той же проблемой в последней сборке --pre (numpy-1.20.0.dev0 + a0028bc) в 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

Рассматриваемая строка просто:

K = np.dot(eigen_leads, trans)

Если это поможет, я мог бы попробовать сохранить массивы на диск и получить их с помощью артефакта Azure.

Похоже на то. Вы используете ту же предварительную версию, с которой я работал правильно.

Вы можете добавить

$env:OPENBLAS_VERBOSE=2

или же

set OPENBLAS_VERBOSE=2

к вашему шаблону, чтобы узнать, какое ядро ​​используется.

Если это поможет, я мог бы попробовать сохранить массивы на диск и получить их с помощью артефакта Azure.

Вероятно, было бы достаточно знать типы и размеры.

Хорошо, воспроизведено за один прогон только неудачного теста с помощью всего лишь numpy + scipy + matplotlib + pytest (и deps), который записывает умножаемые матрицы, а затем загружает артефакты, вот вкладка артефактов:

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

Последний .npz должен быть неудачным (27 МБ). Локально в 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 на Прескотт или Нехалем. Я действительно вижу это в Zen, Sandybridge и Haswell.

Я не могу воспроизвести локально, используя данные вашего npz в Windows.

Я не могу воспроизвести локально, используя данные вашего npz в Windows.

FWIW в Azure я могу воспроизвести его с данными save-load-round-tripped, потому что теперь он не работает на предпоследней строке исполняемого кода здесь:

    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

Так что, по крайней мере, ничего не потеряно в конце Azure из-за шагов np.savez / np.load .

Я пытаюсь пробежать с OPENBLAS_CORETYPE: 'nehalem' чтобы посмотреть, поможет ли.

Так может быть здесь на самом деле две разные ошибки?

Кроме того, установка OPENBLAS_VERBOSE: 2 , похоже, не имеет никакого эффекта, не знаю, почему

После настройки подробного добавьте команду

python -c "import numpy"

Думаю, Pytest, вероятно, ест это.

В четверг, 23 июля 2020 г., 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, чтобы он запустил его самостоятельно после сбоя.

Похоже, OPENBLAS_VERBOSE в Azure говорит «Core: Haswell». Но я не знаю, правильно это или нет.

Я сообщил об ошибке в https://github.com/xianyi/OpenBLAS/issues/2732, и они предположили, что это может быть исправлено в мастере, см. Https://github.com/xianyi/OpenBLAS/issues/2728 . Однако я не знаю, как это лучше всего проверить.

@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 .

Вам следует установить gfortran с помощью choco install -y mingw если вы еще этого не сделали

... это для окон

Вам следует установить gfortran с помощью choco install -y mingw, если вы еще этого не сделали

Это требуется только для 32-битной версии?

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

Я попробую то, что вы предлагаете выше, с помощью choco install -y mingw только выясню, что такое /path/to/openblas.a - предположительно, запустив tools/openblas_support.py (?).

Да, python tools/openblas_support.py выводит, где найти openblas.a

Вам нужен гфортран. На лазурных машинах установлена ​​64-разрядная версия mingw. Если вы 32-битный, вызов немного другой. Вам также необходимо установить -m32 (но только для 32-битных).

Я просто дословно скопировал большую часть https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml, используя master ветку NumPy, чтобы сначала воспроизвести ошибку, и мне удалось получить это 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

... похоже, что 32-битного OpenBLAS для 64-битной Windows нет в:

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

Думаю, я мог бы добавить тег, чтобы заставить его использовать 64-битный OpenBLAS?

2 там и 1 все еще строится. Должно быть в течение часа.

Тем временем я добавил:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

И он построен просто отлично. Больше никаких ошибок ! Я перезапущу его несколько раз, чтобы убедиться. Не стесняйтесь пинговать меня, когда 32-разрядные библиотеки OpenBLAS Win64 будут установлены, и я могу легко удалить эти строки и повторно протестировать.

При любых изменениях вы запускаете полный набор тестов :-)

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.

Обратите внимание, что мы можем запускать ночные сборки в любое время, отправив фиксацию в главную ветку.

Хорошо, я подожду, пока увижу новый, чтобы посмотреть, исправлена ​​ли проблема с Windows 10 2004.

@bashtage Есть поводу ?

OpenBLAS все еще не работает в самой последней версии Windows. Очень нестандартно даже получить хорошую отладочную информацию из-за смешанной цепочки инструментов, по крайней мере, для меня.