Numpy: ERREUR: test_big_arrays (test_io.TestSavezLoad) sous OS X + Python 3.3

Créé le 3 oct. 2013  ·  29Commentaires  ·  Source: numpy/numpy

Rapporté par Piet van Oostrum sur la liste de diffusion contre 1.8.0rc1 sur OS X avec Python 3.3:

======================================================================
ERROR: test_big_arrays (test_io.TestSavezLoad)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/testing/decorators.py", line 146, in skipper_func
    return f(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/tests/test_io.py", line 149, in test_big_arrays
    np.savez(tmp, a=a)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py", line 530, in savez
    _savez(file, args, kwds, False)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/npyio.py", line 589, in _savez
    format.write_array(fid, np.asanyarray(val))
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/numpy/lib/format.py", line 417, in write_array
    fp.write(array.tostring('C'))
OSError: [Errno 22] Invalid argument
00 - Bug numpy.lib

Commentaire le plus utile

Salut à tous,

Pourriez-vous essayer ce problème avec la dernière version de Python 3.6, 3.7 et 3.8a car je pense avoir résolu le problème sur OSX avec ce PR (https://github.com/python/cpython/pull/1705).

J'ai un autre PR pour 2.7, mais celui-ci n'est pas encore prêt: /

Merci pour votre avis.

Tous les 29 commentaires

Je peux reproduire cela. Ressemble à un bogue 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())

Ce qui précède fonctionne avec Python 2.7 mais pas avec 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

Les deux Python sont installés à partir des dmgs sur python.org. Je ne trouve pas de problème à ce sujet sur bugs.python.org mais IIRC le module io été complètement réécrit.

Test introduit dans gh-2942.

Ou peut-être s'agit-il d'un autre bogue d'E / S OSX? Rappelez-vous, OSX libc est bogué et a des problèmes dans fwrite / fread lorsqu'il s'agit de blocs de données proches de 2 ** 32, que nous avons dû contourner dans tofile / fromfile ...

Dans tous les cas, il faut évidemment contourner le problème en fractionnant l'écriture
en petits morceaux, non?

(Même si c'est finalement la faute de la libc, python devrait probablement contourner
il lui-même - peut-être 2.7 avait du code pour le faire qui s'est perdu dans
transition.)
Le 3 octobre 2013 à 10h03, "Pauli Virtanen" [email protected] a écrit:

Ou peut-être s'agit-il d'un autre bogue d'E / S OSX? Rappelez-vous, OSX libc est bogué et a
problèmes dans fwrite / fread lors du traitement de blocs de données proches de 2 ** 32 ...

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/numpy/numpy/issues/3858#issuecomment -25607852
.

Re: gh-574 et gh-2806 et gh-3473 La version OSX en question peut être pertinente, peut-être qu'elle échoue maintenant plutôt que d'écrire des ordures comme elle le faisait auparavant?

Oui, nous pouvons contourner ce problème par segmentation. Peut-être que ce problème devrait également être transmis aux développeurs Python, afin qu'ils puissent également implémenter eux-mêmes la segmentation ...

Ah, j'ai oublié ces problèmes. J'ai essayé de tester sur ma machine 10.6, mais là, le même script se bloque. Cela peut être dû au matériel, c'est une machine ancienne.

Est-ce un bloqueur 1.8.0? Je vais le mettre là juste pour qu'il ne soit pas oublié, il puisse toujours être supprimé. Est-ce que quelqu'un sait si cela fonctionne pour Python 3.2?

De plus, IIRC, nous n'avons que des lectures fragmentées, il se peut qu'un test qui écrit un fichier volumineux soit cassé.

Je ne retarderais pas la sortie pour celui-ci, ce n'est pas une régression. Marquer comme connu échec dans la branche 1.8.x s'il n'a pas échoué avant la publication.

@rgommers Est-ce que si échoue uniquement avec OSX et 3.3? Vous dites que cela fonctionne pour python 2.7, est-ce correct?

Cela n'échoue pas pour 2.7, mais le test ne vérifie pas que ce qui est écrit dans le fichier est correct. Ce n'est probablement pas correct, voir les autres problèmes liés par Pauli.

@rgommers Donc OSX en général. Je vais le laisser ouvert dans 1.9-devel pour motiver un correctif et ouvrir un problème.

Ceci est rapporté corrigé dans OS X Mavericks. Cela ne résoudra probablement pas, car la solution appropriée consiste à mettre à niveau le système d'exploitation.

Voir également # 2931.

Clôture, devrait être corrigée par Mavericks. Veuillez rouvrir si le problème persiste.

Cela se produit encore pour moi sur Mavericks avec numpy 1.8.1 et python 3.4 (également 3.3) d'Anaconda; si je commente le décorateur skipif , https://github.com/numpy/numpy/blob/v1.8.1/numpy/lib/tests/test_io.py#L154 échoue.

Le test réussit et les données semblent être chargées correctement, à l'aide de python 2.7 d'Anaconda.

Ce n'est pas nécessairement une faille avec numpy, mais d'autres semblent contourner ce problème ou des problèmes similaires, par exemple https://github.com/torch/torch7-distro/commit/40e65934e071e452f194a9d8c0fd740131babefa (qui est pour lire plutôt qu'écrire, mais Je suis également incapable de lire de gros fichiers sur python 3).

L'exécution du scénario de test à l'aide de Python 3.4 avec numpy 1.8.1 sous Mac OS X 10.9.4 (Mavericks) entraîne l'erreur connue OSError: [Errno 22] Invalid argument . @certik Veuillez rouvrir le numéro!

Un autre point de données - en utilisant OSX 10.9.5 (Mavericks) et j'obtiens le même problème. Je viens de voir ce bug dans le tracker python: https://bugs.python.org/issue24658

Autant le rouvrir. Je ne sais pas si cela sera corrigé lorsque Python résoudra leur part, mais nous le saurons.

Cela se passe ici, les derniers macOS, python (3.6) et numpy.

Pour info toujours ce bug sur les derniers macOS (10.12.6) et Python 3.5.2 (Anaconda 4.2.0).
Quelqu'un a-t-il déterminé une limite supérieure sur la taille des morceaux?

Obtenir cette erreur également, macOS Sierra, python 3.6, numpy

Il semble y avoir du mouvement sur la question de Python, mais peut-être devrions-nous simplement aller de l'avant et découper les écritures.

On dirait que cela ne sera pas corrigé en amont de sitôt. Quelqu'un connaît le dernier statut?

Salut à tous,

Pourriez-vous essayer ce problème avec la dernière version de Python 3.6, 3.7 et 3.8a car je pense avoir résolu le problème sur OSX avec ce PR (https://github.com/python/cpython/pull/1705).

J'ai un autre PR pour 2.7, mais celui-ci n'est pas encore prêt: /

Merci pour votre avis.

@rgommers Avez -vous une chance de tester cela? Tout autre commentaire sur l'état actuel de cette question serait le bienvenu.

Le test test_big_arrays réussit, mais https://github.com/numpy/numpy/issues/3858#issuecomment -25607105 échoue toujours pour moi avec le dernier Python 3.6 livré par Anaconda. Cela n'a probablement pas le correctif CPython. Pas le temps de construire moi-même Python pour le moment, désolé.

@rgommers pouvez-vous revoir cela?

Cela est en effet corrigé pour autant que je sache, du moins avec Python 3.7 d'Anaconda. Aucun autre rapport non plus, donc fermeture. Merci à tous, et à @matrixise en particulier, d'avoir

Cette page vous a été utile?
0 / 5 - 0 notes