MagicStack / MagicStack/uvloop
signal handler sockets error on close leaving loop in 'running' state indefinitely
Personne n'a encore pris cette issue.
- Langage dominant
- Cython
- Étoiles
- 11.9k
- Forks
- 616
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
- uvloop version: 0.19.0 and 0.20.0
- Python version: 3.12
- Platform: linux/aws lambda
- Can you reproduce the bug with
PYTHONASYNCIODEBUGin env?: - Does uvloop behave differently from vanilla asyncio? How?: have observed the same error on asyncio
I have not been able to come up with a reproduction for this as I think it has something to do with how aws lambda freezes and thaws lambdas.
I have an aws lambda using uvloop that handles requests with using loop.run_until_complete. I can't use uvloop.run or aysncio.run since I need client connected to that loop to still be present on the next invocation of the lambda. Occassionally we have observed errors on the lambda with the following stack trace:
[ERROR] OSError: [Errno 9] Bad file descriptor
Traceback (most recent call last):
File "/my_code.py", line 302, in request_handler
self.loop.run_until_complete(_process_records())
File "uvloop/loop.pyx", line 1511, in uvloop.loop.Loop.run_until_complete
File "uvloop/loop.pyx", line 1504, in uvloop.loop.Loop.run_until_complete
File "uvloop/loop.pyx", line 1377, in uvloop.loop.Loop.run_forever
File "uvloop/loop.pyx", line 547, in uvloop.loop.Loop._run
File "uvloop/loop.pyx", line 348, in uvloop.loop.Loop._pause_signals
File "/root/.pyenv/versions/3.12.1/lib/python3.12/socket.py", line 504, in close
self._real_close()
File "/root/.pyenv/versions/3.12.1/lib/python3.12/socket.py", line 498, in _real_close
_ss.close(self)
Because this error happens before the loop sets it's self._running field to 0 this means on the next invocation of the lambda the call to loop.run_until_complete errors with a loop is already running error.
I think the bad file descriptor is caused by some feature of the lambda environment or it could just be some kind of random chance since we have a lot of these running and this happens on very small fraction (<0.01%).
I wrote this patch to catch and ignore the Bad file descriptor error, but don't know if that's the right thing to do in the absence of real test case. If anyone has ideas about how I could produce a test case I am happy to try them out.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par lire dans uvloop/loop.pyx autour de Loop._pause_signals et Loop.run_until_complete, puis examinez le patch catch-exception-on-pause associé. Reproduisez le chemin bad-file-descriptor, y compris des appels répétés à run_until_complete, et ajoutez un test de régression ; c’est terminé lorsque la boucle ne reste pas marquée comme étant en cours d’exécution après l’échec.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- backend, networking
- Type d'issue
- Bug
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 20/100