Numpy: Erro no Azure CI (instância do Windows) com numpy 1.19.0

Ele falha de forma consistente ou apenas de vez em quando? Você tem algum desenvolvedor do Windows que pode tentar construir o projeto em uma máquina local?

Oi,
obrigado!

Ele falhou de forma consistente muitas vezes ... naquele ponto, pensei em perguntar aos desenvolvedores do Azure (meu palpite inicial era que talvez algo tivesse mudado na configuração de suas VMs).

Este link contém a discussão que tive com um desenvolvedor da Microsoft que identificou o problema pode ter sido entorpecido: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html? childToView = 1119179 # comment -1119179

Infelizmente, não tenho ninguém que possa tentar construir o projeto em uma máquina Windows local :(

Então, precisaremos de um conjunto claro de etapas para reproduzir

O azure-pipelines.yml funcionaria?

Aqui está o que usamos (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml) comentado no momento ... você pode ver que é uma configuração bastante padrão, usando Python 3.7 , instalando dependências no arquivo requirements-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) e depois executando os testes.

Como já mencionei, se eu comentar isso e forçar o numpy 1.18.5 tudo a funcionar, parece que o novo 1.19 vai quebrar

Qual é a versão principal e a versão secundária da imagem em execução no Azure? ou seja, o que systeminfo imprime para OS Version ?

Eu poderia encontrar os detalhes das VMs do Azure usadas no Azure Pipelines aqui: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml e o link para software instalado https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md

Não tenho certeza de como executar systeminfo em um pipeline do Azure, alguma sugestão?

Ele é executado a partir da linha de comando e despeja a saída no terminal, para que você possa adicioná-la à sua execução como um comando.

Você poderia fazer isso em um PR executado em CI para ver o que diz. Estou perguntando desde que houve problemas com a compilação 19041 do Windows e pip NumPy.

A resposta estava no segundo link:

Versão do sistema operacional: 10.0.17763 Build 1282

Portanto, minha ideia não dá frutos.

Você diz que sabe que existem alguns problemas com os mecanismos mais recentes do Windows. Provavelmente, ele está relacionado a isso?

Na verdade, é (provavelmente) um bug do Windows introduzido em 19041. Mas você está em uma versão muito mais antiga, então esse não é o problema.

Não afeta Conda NumPy, apenas pip NumPy porque parece haver algum problema com o Windows e o OpenBlas.

Entendo :) Recebi um e-mail informando que o 1.9.1 foi lançado. Vou tentar reativar o pipeline do Azure, que agora instalaria a versão mais recente e ver se funciona, avisarei você

Infelizmente, ainda falha com 1.19.1 https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=45&view=logs&j=50448a2f-9550-51a0-b6c4-5ec64224dd81&t=a6a6804f-777d1-5f53-b76b6776b500d :(

Um bug no OpenBlas.

Aqui está um exemplo de reprodução:

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

As informações de depuração sem símbolos são:

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

Observe que o array deve ser bem grande (10k passa, 12k não) para acionar o bug.

Verificação rápida:

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

passa, mas o kernel padrão ( Zen ), bem como Haswell e Sandybridge , ambos têm violações de acesso.

Talvez valha a pena verificar se aquele HEAD entorpecido, que usa um OpenBLAS 0.3.10 mais recente, também falha. Ou talvez já tenha feito isso?

@mattip não, ainda não tinha tentado. Você quer dizer instalar o bumpy diretamente do master com pip install git+https://github.com/numpy/numpy ? Posso tentar :)

E para sua pergunta @bashtage (Os testes com falha usam numba? O numba 0.50 tem um bug em algumas versões do Windows onde ele usa incorretamente um intrínseco indisponível. Isso causou travamentos em outro projeto.) e-mail, mas não consigo ver neste tópico ... o teste que trava usa as operações numpy e pyfftw . Enquanto ele trava com essa mensagem repentina, é difícil dizer em qual linha ele realmente trava. Mas eu não acho que pyfftw usa numba, pelo menos não é uma de suas dependências

Acabei de tentar instalar o HEAD do NumPy diretamente do repositório GitHub e o windows build é executado até a conclusão - sem travamento repentino: https://dev.azure.com/matteoravasi/PyLops/_build/results?buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

Curiosamente, algumas bibliotecas que têm NumPy como dependência não parecem instalar corretamente (não tenho certeza por que) e alguns testes falham para todos os sistemas operacionais, mas pelo menos não é uma falha completa como antes ...

Nenhum erro ao usar noturno:

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

Acabei de tentar instalar o HEAD do NumPy diretamente do repositório GitHub

Este não tem OpenBLAS a menos que você o construa explicitamente. Por padrão, você obtém um BLAS lento e genérico com pip install git+https://github.com/numpy/numpy.git .

Parece que queremos atualizar o OpenBLAS para 1.19.2, marcando isso.

Acho que posso estar tendo o mesmo problema no último --pre build (numpy-1.20.0.dev0 + a0028bc) no 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

A linha em questão é apenas:

K = np.dot(eigen_leads, trans)

Se ajudar, eu poderia tentar salvar os arrays em disco e retirá-los por meio de um artefato do Azure.

Parece que sim. Você está usando o mesmo pré que eu estava funcionando corretamente.

Você pode querer adicionar

$env:OPENBLAS_VERBOSE=2

ou

set OPENBLAS_VERBOSE=2

ao seu modelo para saber qual kernel está sendo usado.

Se ajudar, eu poderia tentar salvar os arrays em disco e retirá-los por meio de um artefato do Azure.

Provavelmente seria suficiente conhecer os dtipos e dimensões.

Ok, reproduzido em uma única execução do teste com falha apenas com numpy + scipy + matplotlib + pytest (e deps) que grava as matrizes sendo multiplicadas e, em seguida, carrega os artefatos, aqui está a guia de artefatos:

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

O último .npz deve ser o que falhou (27 MB). Localmente no Linux, ele pontilha muito bem:

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

Estou trabalhando para fazer com que OPENBLAS_VERBOSE funcione, mas parece que sempre que uso pytest -s para não capturar a saída, ela realmente passa. Isso pode ser apenas uma casualidade, no entanto, veremos ...

Engraçado, eu também vejo isso com o reprodutor acima agora.

Não vejo se definir OPENBLAS_CORETYPE como Prescott ou Nehalem. Eu vejo isso com Zen, Sandybridge e Haswell.

Não consigo reproduzir localmente usando os dados do seu npz no Windows.

Não consigo reproduzir localmente usando os dados do seu npz no Windows.

FWIW no Azure, posso reproduzi-lo com os dados salvos-carregados-round-trip, porque agora ele falha na penúltima linha do código executado aqui:

    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

Portanto, pelo menos nada é perdido no final do Azure devido às etapas de np.savez / np.load .

Estou tentando uma corrida com OPENBLAS_CORETYPE: 'nehalem' para ver se ajuda, no entanto.

Então, talvez haja realmente dois bugs diferentes aqui?

Além disso, definir OPENBLAS_VERBOSE: 2 não parece ter nenhum efeito, não sei por que

Depois de definir verbose, adicione um comando

python -c "import numpy"

Pytest provavelmente está comendo isso, eu acho.

Na quinta-feira, 23 de julho de 2020, 19:04 Eric Larson [email protected] escreveu:

Além disso, definir OPENBLAS_VERBOSE: 2 não parece ter qualquer efeito, não
Claro porque

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

Este comando localmente não me dá nenhuma saída detalhada:

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

Mas talvez meu sistema OpenBLAS seja muito antigo. Enviarei um commit para o Azure para que ele execute sozinho após a falha.

Parece que OPENBLAS_VERBOSE no Azure diz "Core: Haswell". Não sei se isso está correto ou não.

Eu relatei o erro em https://github.com/xianyi/OpenBLAS/issues/2732 e eles sugeriram que poderia ser corrigido no mestre, consulte https://github.com/xianyi/OpenBLAS/issues/2728 . Não tenho ideia da melhor maneira de testar isso, no entanto.

@mattip Sabemos que isso é fechado por MacPython / openblas-libs # 35? Não precisamos esperar até o lançamento da próxima semana?

@charris Acho que este problema ainda está aberto e provavelmente será necessário um backport.

Alguém com um reprodutor poderia tentar construir numpy com este commit para obter os binários mais recentes do OpenBLAS? Então, algo como (talvez com erros de digitação)

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 .

Você deve ter instalado o gfortran com choco install -y mingw se ainda não o fez

... isto é para windows

Você deve ter instalado o gfortran com choco install -y mingw se ainda não o fez

Isso é necessário apenas para 32 bits?

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

Vou tentar o que você sugere acima com choco install -y mingw assim que descobrir o que é /path/to/openblas.a - presumivelmente por executar tools/openblas_support.py (?).

Sim, python tools/openblas_support.py imprime onde encontrar openblas.a

Você precisa do gfortran. As máquinas azuis têm o mingw de 64 bits instalado. Se você tem 32 bits, a invocação é um pouco diferente. Você também precisa definir -m32 (mas apenas para 32 bits).

Acabei de copiar literalmente a maior parte de https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml usando master branch de NumPy para reproduzir o erro pela primeira vez e tive sucesso em ter é segfault .

Em seguida, mudei para mattip/issue-16913 e ele falha com um erro de download de URL para:

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

... parece que não há OpenBLAS de 32 bits para Windows de 64 bits em:

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

Eu acho que poderia adicionar a tag para fazê-lo usar o OpenBLAS de 64 bits?

2 estão lá e 1 ainda está sendo construído. Deve levantar dentro de uma hora.

Nesse ínterim, adicionei:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

E construiu muito bem. Não há mais segfaults ! Vou executá-lo novamente algumas vezes para ter certeza. Sinta-se à vontade para me enviar um ping quando as libs OpenBLAS Win64 de 32 bits estiverem ativas e eu puder remover facilmente essas linhas e testar novamente.

Qualquer mudança que você execute em todo o conjunto de testes :-)

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

Parece que os de 32 bits estão funcionando, e isso também funciona .

Vou dar uma corrida ao conjunto de testes completo agora

Ele recebe um erro estranho de coleção de teste envolvendo 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

Você não deve perder mais tempo com esse outro assunto - posso esperar até a próxima semana e testar o semanal que espero ter o BLAS.

Observe que podemos executar as compilações noturnas a qualquer momento, enviando um commit para o branch master.

Ok, vou esperar até ver um novo para ver se o problema com o Windows 10 2004 foi corrigido.

@bashtage Alguma atualização sobre isso?

O OpenBLAS ainda está quebrado na versão mais recente do Windows. É muito fora do padrão até mesmo obter boas informações de depuração por causa da cadeia de ferramentas mista, pelo menos para mim.