Process can hang at exit: the non-daemon logistro stderr reader waits on a pipe that chrome_crashpad_handler (orphaned, macOS) still holds

Ouverte
  • Quelque chose ne va pas ?
#319 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
46/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
backend

Piste de recherche

Start by tracing how choreographer starts and closes the browser process and how logistro.getPipeLogger creates and manages its stderr reader; the issue identifies the reader thread as the point that keeps Python alive. Check whether logistro or choreographer owns that thread’s lifecycle, then reproduce the exit hang on macOS with the reported Chrome and package versions. Done means the reader cannot block interpreter exit while the browser’s stderr pipe remains open, with appropriate coverage for the chosen fix.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

After fig.to_image() (Kaleido 1.4.0, choreographer 1.4.0, logistro 2.0.1) has returned, the Python process can hang at exit. It stays at 0 % CPU in threading._shutdown, joining the browser_procThread reader that logistro.getPipeLogger("browser_proc") starts. That thread is not a daemon thread and is blocked in os.read on the browser's stderr pipe. It only returns at EOF, and EOF never comes while any process still holds the write end. On macOS, chrome_crashpad_handler holds it.

Environment

  • macOS
  • Python 3.13
  • kaleido 1.4.0, choreographer 1.4.0, logistro 2.0.1, plotly 7.1.0
  • System Chrome 156.0.8078.74 and 156.0.8078.80

What we measured

  • Who holds the pipe. When Chrome starts, a new chrome_crashpad_handler appears with PPID 1 and a session and process group of its own, so it double-forked with setsid. lsof shows its fd 2 as the other end of the logistro reader's pipe, in 5 of 5 runs. Its --database is the user's real Chrome profile (~/Library/Application Support/Google/Chrome/Crashpad), not the temporary --user-data-dir.
  • The handler outlives close(). Right after Browser.close() returns, the handler is still running; it usually exits about 1 to 1.5 s later. While it lives, the reader thread cannot end, and an interpreter that is exiting waits for it.
  • The cause, confirmed. We sent SIGSTOP to the handler after fig.to_image() returned. The process then hangs at exit, every time, and exits at once after SIGCONT.
  • Under real load. In a test suite with 12 concurrent processes, 2 of them passed their tests and then never exited. In the hung processes, sample shows the main thread in threading._shutdown joining two logistro pipe-reader threads blocked in os.read. 14 handlers had been orphaned at the time.
  • Other remedies don't reach it.
    • Killing the browser's process group doesn't reach the handler, because it has left that group and session.
    • --disable-breakpad, which choreographer already passes, doesn't stop macOS Chrome from starting the handler. We didn't test --disable-crash-reporter.
    • Linux and Windows were not measured.

Request

Make the reader thread a daemon thread: Thread(..., daemon=True) in logistro.getPipeLogger, or a way for choreographer to ask for one. A logging reader should not decide whether the interpreter can exit, and no process-group or tree walk can reach a process that has left the group.

A bounded join in Browser.close() would not help on its own. The thread stays non-daemon, so threading._shutdown still joins it at exit. It only helps together with a daemon thread, or with a reader that stops by itself, for example by polling the browser process between reads with a select timeout.

Which project should own the fix is your call, since the thread lives in logistro and choreographer is the consumer. Happy to provide more detail.

Langage dominant
Python
Étoiles
17
Forks
10
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de plotly/choreographer

Toutes les issues de plotly/choreographer

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.