Numpy: ERRO: test_big_arrays (test_io.TestSavezLoad) no OS X + Python 3.3

Eu posso reproduzir isso. Parece um bug do Python 3.x.

import os
import sys
import time


if sys.maxsize > 2**32:
    print('64-bit')
else:
    print('32-bit, exiting')
    sys.exit(0)

fname = 'write_large_bytestring.txt'
tmp = open(fname, 'wb')
try:
    L = (1 << 31) + 100000
    tmp.write(b'abc' * 2**32)
finally:
    tmp.close()
    os.remove(fname)
    print('Elapsed time: %s s' % time.clock())

O acima funciona com Python 2.7, mas não com 3.3:

$ python tmp3.py 
64-bit
Elapsed time: 7.896957 s

$ python3.3 tmp3.py 
64-bit
Elapsed time: 50.149956 s
Traceback (most recent call last):
  File "tmp3.py", line 16, in <module>
    tmp.write(b'abc' * 2**32)
OSError: [Errno 22] Invalid argument

$ ulimit
unlimited

Ambos os Python são instalados a partir do dmgs em python.org. Não consigo encontrar um problema para isso em bugs.python.org mas IIRC o módulo io foi completamente reescrito.

Teste introduzido em gh-2942.

Ou talvez este seja outro bug de E / S do OSX? Lembre-se, OSX libc tem bugs e tem problemas em fwrite / fread ao lidar com blocos de dados próximos a 2 ** 32, que tivemos que contornar em tofile / fromfile ...

Em qualquer caso, obviamente temos que contornar isso dividindo a escrita
em pedaços menores, certo?

(Mesmo que seja, em última instância, culpa da libc, o python provavelmente deve contornar
ele próprio - possivelmente 2.7 tinha um código para fazer isso que se perdeu no
transição.)
Em 3 de outubro de 2013 10:03, "Pauli Virtanen" [email protected] escreveu:

Ou talvez este seja outro bug de E / S do OSX? Lembre-se, OSX libc é buggy e tem
problemas em fwrite / fread ao lidar com blocos de dados próximos a 2 ** 32 ...

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/numpy/numpy/issues/3858#issuecomment -25607852
.

Re: gh-574 e gh-2806 e gh-3473 A versão OSX em questão pode ser relevante, talvez agora falhe em vez de escrever lixo como fazia anteriormente?

Sim, podemos contornar isso dividindo. Talvez esse problema também deva ser encaminhado para desenvolvedores de Python, para que eles também possam implementar a fragmentação ...

Ah, esqueci esses problemas. Tentei testar na minha máquina 10.6, mas lá o mesmo script simplesmente trava. Pode ser devido ao hardware, porém, é uma máquina antiga.

Este é um bloqueador 1.8.0? Vou colocá-lo lá para não ser esquecido, pode sempre ser removido. Alguém sabe se funciona para Python 3.2?

Além disso, IIRC, temos apenas leituras em partes, pode ser que um teste que grava um arquivo grande esteja quebrado.

Eu não atrasaria a liberação por este, não é uma regressão. Marque-a como falha conhecida no branch 1.8.x se ela não tiver falhado antes do lançamento.

@rgommers falha somente com OSX e 3.3? Você diz que funciona para o python 2.7, correto?

Não falha no 2.7, mas o teste não verifica se o que está escrito no arquivo está correto. Provavelmente não está correto, veja outras questões que Pauli vinculou.

@rgommers So OSX em geral. Vou deixá-lo aberto no 1.9-devel para motivar uma correção e abrir um problema.

Isso foi relatado como corrigido no OS X Mavericks. Provavelmente, isso não resolverá, pois a solução adequada é atualizar o sistema operacional.

Veja também # 2931.

Fechando, deve ser consertado por Mavericks. Abra novamente se o problema persistir.

Isso ainda está acontecendo para mim no Mavericks com numpy 1.8.1 e python 3.4 (também 3.3) do Anaconda; se eu comentar o decorador skipif , https://github.com/numpy/numpy/blob/v1.8.1/numpy/lib/tests/test_io.py#L154 falhará.

O teste passa e os dados parecem ser carregados corretamente, usando o python 2.7 do Anaconda.

Isso não é necessariamente uma falha com numpy, mas outros parecem estar trabalhando em torno deste ou de problemas semelhantes, por exemplo, https://github.com/torch/torch7-distro/commit/40e65934e071e452f194a9d8c0fd740131babefa (que é para ler em vez de escrever, mas Também não consigo ler arquivos grandes no Python 3).

Executar o caso de teste usando Python 3.4 com numpy 1.8.1 no Mac OS X 10.9.4 (Mavericks) resulta no erro OSError: [Errno 22] Invalid argument conhecido. @certik Por favor, reabra o problema!

Outro ponto de dados - usando OSX 10.9.5 (Mavericks) e recebo o mesmo problema. Acabei de ver este bug no rastreador Python: https://bugs.python.org/issue24658

Pode muito bem reabrir isso. Não sei se será corrigido quando o Python resolver a parte deles, mas vamos descobrir.

Acontece aqui, o mais recente macOS, python (3.6) e numpy.

Ainda estou vendo este bug no último macOS (10.12.6) e Python 3.5.2 (Anaconda 4.2.0).
Alguém descobriu um limite máximo para o tamanho dos pedaços?

Recebendo este erro também, macOS Sierra, python 3.6, numpy

Parece haver alguma movimentação na questão do Python, mas talvez devêssemos ir em frente e dividir as gravações.

Parece que isso não será corrigido no upstream tão cedo. Alguém sabe o status mais recente?

Olá a todos,

Você poderia tentar este problema com a última versão do Python 3.6, 3.7 e 3.8a porque eu acho que corrigi o problema no OSX com este PR (https://github.com/python/cpython/pull/1705).

Tenho outro PR para 2.7, mas este ainda não está pronto: /

Obrigado pelo seu feedback.

@rgommers Alguma chance de você testar isso? Qualquer outro feedback sobre o status atual disso seria bem-vindo.

O teste test_big_arrays passa, mas https://github.com/numpy/numpy/issues/3858#issuecomment -25607105 ainda falha para mim com o Python 3.6 mais recente enviado pela Anaconda. Isso provavelmente não tem a correção CPython embora. Não há tempo para construir Python sozinho agora, desculpe.

@rgommers você pode revisitar isso?

Até onde eu sei, isso foi corrigido, pelo menos com o Python 3.7 do Anaconda. Nenhum outro relatório também, então fechando. Obrigado a todos, e @matrixise em particular por consertar isso.