Il semble que Python 3.7 sur Cygwin ait quelques problèmes avec Werkzeug. J'ai une application Flask complexe et j'ai décidé de mettre à niveau mon virtualenv vers 3.7 et tout à coup je vois cet avertissement

0 [main] python3.7 1642 child_info_fork::abort: l'espace d'adressage requis par 'bit_generator.cpython-37m-x86_64-cygwin.dll' (0x600000) est déjà occupé

Ou tout simplement planter avec une BlockingIOError.

Traceback (most recent call last):
  File "run.py", line 5, in <module>
    app.run(debug=True)
  File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/flask/app.py", line 990, in run
    run_simple(host, port, self, **options)
  File "/cygdrive/c/maga/personale/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/serving.py", line 1050, in run_simple
    run_with_reloader(inner, extra_files, reloader_interval, reloader_type)
  File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/_reloader.py", line 339, in run_with_reloader
    sys.exit(reloader.restart_with_reloader())
  File "/cygdrive/c/py/venvs/cyg/lib/python3.7/site-packages/werkzeug/_reloader.py", line 183, in restart_with_reloader
    exit_code = subprocess.call(args, env=new_environ, close_fds=False)
  File "/usr/lib/python3.7/subprocess.py", line 339, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1482, in _execute_child
    restore_signals, start_new_session, preexec_fn)
BlockingIOError: [Errno 11] Resource temporarily unavailable

On ne sait pas quelle partie est le coupable. Si j'essaie de vider mon init.py, il semble qu'il y ait des problèmes avec certaines chaînes d'importation (importer un fichier qui importe un autre fichier). Je pensais que l'un des coupables était l'importation de sous-processus, mais ce n'est pas le cas.

Y a-t-il quelque chose que je puisse faire pour obtenir plus de sortie afin de donner plus d'informations pour résoudre ce problème ? Je ne peux pas vraiment copier l'intégralité du code ici et il semble qu'un projet simple n'ait pas ce problème.

0
maugch 16 sept. 2020 à 12:27

1 réponse

Meilleure réponse

Dans une installation correcte de Cygwin, les bibliothèques partagées sont toujours exécutées à une adresse supérieure à celle de votre cas d'échec de fourche.

Pour voir la plage attendue, vous pouvez consulter la base de données d'adresses de base.
Sur mon système actuel :

$ rebase -si | awk '{ print $3, $1}' |sort  |head -n 5
0x0003ce2c0000 /usr/libexec/coreutils/libstdbuf.so
0x0003ce2d0000 /usr/lib/texinfo/XSParagraph.dll
0x0003ce2e0000 /usr/lib/texinfo/Parsetexi.dll
0x0003ce310000 /usr/lib/texinfo/MiscXS.dll
0x0003ce320000 /usr/lib/sasl2_3/cygscram-3.dll

$ rebase -si | awk '{ print $3, $1}' |sort -r |head -n 5
0x0003fffd0000 /usr/bin/cygEGL-1.dll
0x0003fffa0000 /usr/bin/cygEMF-1.dll
0x0003fff20000 /usr/bin/cygFLAC-8.dll
0x0003ffea0000 /usr/bin/cygGL-1.dll
0x0003ffe30000 /usr/bin/cygGLU-1.dll

Donc ou votre base de données est endommagée et le rebasage n'a pas été effectué correctement, ou un BLODA interfère dans le chargement de vos dll correctement.

1
matzeri 16 sept. 2020 à 11:25