macOS: melt occasionally never exits after the avformat consumer thread is gone

Aperta
  • Qualcosa non va?
#1,333 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@eseifert ci sta già lavorando.

Dal 25/10/2026.

  • #1353 di @eseifert — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, macos
Ambito
backend, cli

Direzione di ricerca

Begin with the supplied melt command and the reported consumer_is_stopped wait loop; inspect the avformat consumer-thread lifecycle and compare behavior with #1326. Reproduce the arm64 macOS soak using the supplied XML, then capture a sample when it hangs. Done means repeated renders no longer leave melt waiting after the avformat thread is gone.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Split out from #1326, as requested.

Summary. On macOS arm64, about 1 in 250 headless melt renders never exits. melt's main thread stays in its wait loop polling consumer_is_stopped, but the avformat consumer thread is already gone. The render doesn't finish or crash, so it waits forever. We've seen it twice in about 500 renders, once on master (89fbe37) and once on fix-property-locale (99383f4), so #1326's fix doesn't cause it and doesn't cure it.

Setup. This is the soak from #1326. libmlt (framework only) is built from each commit and dropped into its own copy of Shotcut 26.8.1's app bundle. The two copies alternate rendering the same document: an XML with LC_NUMERIC="C" on the root, three avformat-novalidate chains and a color producer. Command:

melt soak.mlt -consumer avformat:out.mp4 vcodec=libx264 crf=18 preset=medium acodec=aac

The runner is GitHub's macos-latest (macOS 26.6.2, arm64), with LANG/LC_ALL = en_US.UTF-8. Each render normally takes 2 to 7 s.

What the hung process looks like. The driver gives each render 60 s, then runs sample on it and kills it. Sample of the branch's hang (render 54 of 200, killed at 66.7 s): https://gist.github.com/tydude001/aa8eb4fa6996ed26134c9b257471f525#file-arm64-hang-99383f4-render54-sample-txt

  • Main thread: 2753 of 2756 samples in main → nanosleep. The rest are SDL_WaitEventTimeout and one consumer_is_stopped → mlt_properties_get_int. That's melt's wait-for-the-consumer loop.
  • No avformat consumer_thread, and no slice or encoder worker threads.
  • Sixteen idle av:h264:df0–df3 decoder threads (four producers' worth), all in pthread_cond_wait.
  • NSEventThread and one workqueue thread, both idle.
  • Nothing is in setlocale, and nothing is blocked on a mutex.
  • melt's stderr stops right after libx264 opens (the last line is x264's "dc" option is deprecated warning). The footprint is 50 MB, and nothing in the output says how far it got.

So it looks less like a deadlock between two threads and more like the consumer thread exited, or never started encoding, without the consumer ever reporting stopped. My guess is that's a running/joined flag the main loop never sees change, but I haven't confirmed that.

The earlier hang (master, the first arm64 run in #1326) ran for over an hour before I cancelled it, and there was no timeout or sample then. So the sample above is the only stack we have.

Does it need the locale path? We ran stock Shotcut 26.8.1 melt with LC_NUMERIC removed from the document root, so mlt_property_get_string_l_tf never calls setlocale. Result: 0 hangs and 0 crashes in 600 renders (300 under en_US.UTF-8, 300 with LC_NUMERIC=C in the environment). At about 2 in 500, 600 clean renders would happen by chance about 1 time in 10, so that leans toward the hang needing a locale on the document, but it isn't conclusive. It hasn't shown up on the Intel runner (macos-15-intel, 200 renders per build).

I can rerun with more renders per arm, a debug build, or extra logging if that would help.

Lingua principale
C
Stelle
1.9k
Fork
397
Merge medio
2g 11h
PR unite (30g)
16

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mltframework/mlt

Tutte le issue di mltframework/mlt

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.