[gelöst] ffmpeg: Speicherzugriffsfehler

[kreuzschnabel]

Nahmd, mein ffmpeg mag mich nicht mehr

Aufgabe: Wenn was Gutes im TV kommt, lasse ich Kaffeine mitschneiden (Empfang über WinTV-Stick) und rechne das Ganze dann hinterher mit ffmpeg klein, um es abzulegen und mir später anzusehen.

Das sieht dann etwa so aus (hier 1 Video- und 3 Audiostreams):

Code: Alles auswählen

ffmpeg -i sendung1.m2t -ss 00:05:11 -to 01:34:00 -c:v hevc -crf 23 -c:a libopus -b:a 128k -sample_fmt flt -map 0:0 -map 0:1 -map 0:2 -map 0:4 "Sendung1.mkv"

Das lief bislang so problemlos, dass ich drei bis vier Instanzen über Nacht parallel laufen lassen konnte, und morgens war alles fertig.

In letzter Zeit (seit gefühlt 3 Wochen) bricht aber immer häufiger einer von 2–3 parallelen Tasks mit der Meldung „Speicherzugriffsfehler“ ab:

Code: Alles auswählen

Speicherzugriffsfehler=32.9 size=  327936kB time=00:34:03.27 bitrate=1314.8kbits/s speed=0.357x    
volker@marvin:~/Aufnahmen/Filme$ 

(Das „=32.9“ hat nichts zu sagen, das kommt von der Statuszeile, die vorher da stand, und hatte ein q davor.)

Das passiert erratisch und nicht reproduzierbar. Wenn ich den Task neu starte, kann er tadellos durchlaufen. Der Abbruch kann überall erfolgen, nach paar Minuten Laufzeit, nach 34 Minuten Laufzeit (wie oben) oder kurz vor Schluss erst.

Ich hatte erst einen Hardwarefehler vermutet, aber Wechsel der SATA-Verkabelung (und sogar der SSD selbst) ändert nichts. Dann hab ich ergoogelt, dass dieser im Deutschen etwas unspezifische Fehler dem englischen „segmentation fault“ entspricht und einen Zugriffsversuch auf einen nicht zugewiesenen Speicherbereich bezeichnet.

Woran kann das liegen? Das einzige, was ich mir vorstellen kann, ist, dass ffmpeg große Datenmengen auf /tmp ablegt und meine Systempartition vollläuft. Wenn ja, wie könnte ich ffmpeg das abgewöhnen? Ist echt ärgerlich gerade.

Eckdaten:

• ffmpeg version 4.3.3-0+deb11u1 Copyright (c) 2000-2021 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6)
• Debian 11 + KDE Plasma aktuell
• 16 GB RAM, 500 GB SSD (150 GB frei)

--ks

[DeletedUserReAsG]

Zu Segfaults sollten auch weitere Infos im Journal stehen. Ansonsten wären übliche Verdächtige: RAM (mal mit memtest86+ durchtesten), nicht installierter/geladener Microcode für die CPU, thermisches Problem, Libs aus Fremdquellen. Die Liste ist nicht abschließend, aber kann man erstmal durchgehen – beginnend mit dem Journal.

[kreuzschnabel]

Danke schonmal für die Anregungen!

• journalctl wirft für den Zeitpunkt nichts raus.
• memtest86+ läuft klaglos durch, 0 errors. Hynix und Ramaxel gemischt, aber bis jetzt haben die sich gut vertragen
• intel-microcode ist schon installiert. CPU ist i7-3770, Intel gibt mit Stand 2018 Revision 0x20 an, dann wird 0x21 wohl aktuell sein.

  Code: Alles auswählen

  [    0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13

• thermisches Problem: unwahrscheinlich, Gehäuse ist normal (28 °C), CPU wurde vor 9 Monaten frisch eingebaut und gewärmeleitpastet, Cores sind bei der Arbeit stabil auf 70–75 °C.
• nur libs aus Debian-Quellen installiert.

Ich hab allerdings an den RAM-Modulen jetzt etwas gewackelt und durchgetauscht mal beobachten.

--ks

[hikaru]

Um hoffentlich zu einer sinvolleren Fehlrmeldung zu kommen, lass mal fmpeg über gdb laufen!*

1. Füge das zu deiner sources.list hinzu:

Code: Alles auswählen

deb http://deb.debian.org/debian-debug/ bullseye-debug main

2. Dann installiere gdb, ffmpeg-dbgsym und libc6-dbgsym:

Code: Alles auswählen

# apt update && apt install gdb ffmpeg-dbgsym libc6-dbgsym

3. Lade gdb mit ffmpeg (zwecks besserer Fehlermeldungen ohne Lokalisierung):

Code: Alles auswählen

$ LANG= gdb ffmpeg

4. Lade deine Befehlszeile:

Code: Alles auswählen

(gdb) -i sendung1.m2t -ss 00:05:11 -to 01:34:00 -c:v hevc -crf 23 -c:a libopus -b:a 128k -sample_fmt flt -map 0:0 -map 0:1 -map 0:2 -map 0:4 "Sendung1.mkv"

5. Starte das Ganze:

Code: Alles auswählen

(gdb) run

Beim Segfault wirst du eine kurze Meldung von gdb bekommen. Sowas z.B. bei manuellem Abbruch:

Code: Alles auswählen

Thread 1 "ffmpeg" received signal SIGINT, Interrupt.
0x00007ffff0c034c9 in ?? () from /lib/x86_64-linux-gnu/libopus.so.0

6. Ein Backtrace liefert mehr Infos:

Code: Alles auswählen

(gdb) bt
#0  0x00007ffff0c034c9 in  () at /lib/x86_64-linux-gnu/libopus.so.0
#1  0x00007ffff0bff713 in  () at /lib/x86_64-linux-gnu/libopus.so.0
#2  0x00007ffff0bf6e3e in  () at /lib/x86_64-linux-gnu/libopus.so.0
#3  0x00007ffff0c26425 in  () at /lib/x86_64-linux-gnu/libopus.so.0
#4  0x00007ffff0c2a334 in  () at /lib/x86_64-linux-gnu/libopus.so.0
#5  0x00007ffff0c2a887 in opus_multistream_encode_float () at /lib/x86_64-linux-gnu/libopus.so.0
#6  0x00007ffff68287db in  () at /lib/x86_64-linux-gnu/libavcodec.so.58
#7  0x00007ffff65e184b in avcodec_encode_audio2 () at /lib/x86_64-linux-gnu/libavcodec.so.58
#8  0x00007ffff65e22c9 in  () at /lib/x86_64-linux-gnu/libavcodec.so.58
#9  0x00007ffff65e240f in avcodec_send_frame () at /lib/x86_64-linux-gnu/libavcodec.so.58
#10 0x0000555555582bdd in do_audio_out (frame=<optimized out>, ost=0x555555611e80, of=<optimized out>) at src/fftools/ffmpeg.c:929
#11 reap_filters (flush=flush@entry=0) at src/fftools/ffmpeg.c:1504
#12 0x0000555555586bfd in transcode_step () at src/fftools/ffmpeg.c:4622
#13 transcode () at src/fftools/ffmpeg.c:4666
#14 0x00005555555607fe in main (argc=14, argv=0x7fffffffe1f8) at src/fftools/ffmpeg.c:4871

Heb den Backtrace auf und wiederhole das mehrfach, bis du drei oder vier Segfaults mit identischen Inputs hast!
Falls der Backtrace System hat (z.B. immer in der selben Lib auftritt), liegt ein Bug nahe. Falls nicht, dürften es externe Faktoren (z.B. Hardware) sein.

gdb macht die Sache deutlich langsamer.


*) Disclaimer: Meine Kenntnisse zu gdb sind rudimentär und meine Anweisungen daher vermutlich verbesserungsfähig.

[MSfree]

gdb macht die Sache deutlich langsamer.

Nicht unbedingt. Solange du nur das Programm ausführst bis es zum Segfault kommt, bremst gdb kaum bis gar nicht. Führst du allerdings Software aus, die nicht optmiert ist und speziell zum Debuggen kompiliert und gelinkt wurde, dann ist die Software bereits ohne Debugger deutlich langsamer.

Was allerdings deutlich bremst, sind bedingte Breakpoints. Also solche Stoppunkte, die zum Beispiel beim erreichen eines Wertes einer Variablen aktiviert werden.

Man kann aber auch einfach mit ulimit Coredumps aktivieren. Dann läßt man die Software ganz normal laufen und wenn es dabei zu einem Segfault kommt, wird ein Speicherabbild auf die Platte geschrieben. Dieses kann man nachträglich in den Debugger laden und z.B. ein Backtrace erstellen oder auch Variablen abfragen.

Code: Alles auswählen

ulimit -c unlimited

ermöglicht das Erezugen von Coredumps in der aktuell laufenden Shell. Hier muß dann auch die Software gestartet werden. Das Limit gillt nicht global, muß also auch nicht wieder zurück gesetzt werden, das Beenden der Shell reicht aus.

[kreuzschnabel]

Danke an hikaru und MSfree für die Anregungen. Momentan scheint das Problem nicht mehr akut zu sein; über Nacht sind drei Tasks parallel durchgelaufen. Vielleicht hat mein RAM-Umstecken gestern ein Kontaktproblem bereinigt. Aber das kann natürlich jederzeit wiederkommen

Mir hilft es schon zu wissen, dass der Fehler ganz grob im Bereich Arbeitsspeicher zu suchen ist; ich hatte auch schon die SSD im Verdacht, da ffmpeg ja nur relativ wenig RAM belegt und größtenteils auf dem Festspeicher werkelt.

--ks

[hikaru]

gdb macht die Sache deutlich langsamer.

Nicht unbedingt. Solange du nur das Programm ausführst bis es zum Segfault kommt, bremst gdb kaum bis gar nicht. Führst du allerdings Software aus, die nicht optmiert ist und speziell zum Debuggen kompiliert und gelinkt wurde, dann ist die Software bereits ohne Debugger deutlich langsamer.

Stimmt, danke!
Ich habe das gerade mal an ffmpeg mit gdb und strace getestet und die Encodierungsgeschwindigkeit unterscheidet sich im beiden Fällen praktisch gar nicht im Vergleich zum normalen Aufruf.
Das Ähnlichste was ich mal in einen Debugger gesteckt hatte war mpv (oder damals noch mplayer?). Der Unterschied war enorm, genau wie bei Webbrowsern.

Man kann aber auch einfach mit ulimit Coredumps aktivieren. Dann läßt man die Software ganz normal laufen und wenn es dabei zu einem Segfault kommt, wird ein Speicherabbild auf die Platte geschrieben.

Auch dafür: Danke!

[kreuzschnabel]

Ich hab der Maschin’ heute mal extra Futter gegeben (Archivbestände auf H.265 rekodiert), und sie läuft jetzt fast 24 Stunden klaglos durch.

Dann gehe ich mal davon aus, dass meine RAM-Modul-Umsteckung das Problem behoben hat – vielleicht war da ein besonders empfindliches direkt neben der CPU oder so.

Danke fürs Mitdenken, ich betrachte das als erledigt.

--ks

[kreuzschnabel]

Abschließende Bemerkung:

Nachdem der Fehler nach allen hardwareseitigen Optimierungsmaßnahmen noch immer sporadisch auftrat, habe ich per snap die aktuelle ffmpeg-Version 4.4.1-2 installiert und arbeite damit. In zwei Tagen Archivmaterial-Rerendern bislang kein einziger Segfault-Abbruch. Allerdings im sequenziellen Arbeiten, keine parallelen ffmpeg-Tasks.

Das ist bei nicht-reproduzierbar auftretenden Fehlern natürlich immer zufallsbedingt und lässt keine eindeutigen Schlüsse zu, aber ich neige dazu, die neuere Version von ffmpeg für in dieser Hinsicht stabiler zu halten.

--ks

[kreuzschnabel]

Endgültiger Nachtrag:

Mit den beschriebenen Maßnahmen wurden die Fehler seltener, aber verschwanden nicht völlig Das kann natürlich auch natürliches Rauschen sein, sprich Zufall.

Nach eingehenden Tests mit mehreren dazu beschafften CPUs stellt sich heraus, dass der Fehler mit einer anderen i7-3770 ebenso sporadisch auftritt, mit jeglicher i5-3xyz jedoch nicht (oder so selten, dass er im Einsatzzeitraum nicht dazu kam). Speicher ist laut memtest86 fehlerfrei. Was mich vermuten lässt, dass mein Mainboard (lenovo mahobay) oder Chipsatz (vermutlich Q75 oder Q77) einfach nicht für den Dauerverkehr oder die thermischen Nebenwirkungen eines stundenlangen Videorenderns mit 8 Threads konstruiert ist und irnkwann nicht mehr mitkommt.

Ich lass jetzt die i5-3470 drin und lebe damit, dass alles 50 Prozent länger braucht, solange es dafür zuverlässig fertig wird und nicht mittendrin von vorn gestartet werden muss

--ks

[MSfree]

...dass der Fehler mit einer anderen i7-3770 ebenso sporadisch auftritt, mit jeglicher i5-3xyz jedoch nicht

Der i7-3770 ist ein Vierkerner, der Hyperthreading unterstützt, also 8 Threads parallel abarbeiten kann. Der i5-3xxx ist zwar auch ein Vierkerner, jedoch ohne Hyperthreading. Hier laufen nur 4 Threads parallel ab. Zwar kann man auf dem i5 auch mehr als 4 Threads laufen lassen, die weiteren Threads laufen dann aber nie parallel sondern bekommen ihre Zeitscheibe vom Scheduler.

Hier könnte auch das beobachtete Problem liegen. Irgendwo ist der ffmpeg Code nicht Threadsafe und läuft irgendwann in ein Problem. Je mehr Threads parallel abgearbeitet werden können, desto größer ist die Wahrscheinlichkeit, in so ein Problem zu laufen, weshalb es beim i7 eher auftritt als beim i5. Bei einem modernen Treadripper mit 24 Kernen und 48 Threads dürfte das Problem sogar noch viel eher auftreten.

[kreuzschnabel]

Der i7-3770 ist ein Vierkerner, der Hyperthreading unterstützt, also 8 Threads parallel abarbeiten kann. Der i5-3xxx ist zwar auch ein Vierkerner, jedoch ohne Hyperthreading. Hier laufen nur 4 Threads parallel ab.

Soweit bekannt, danke

Irgendwo ist der ffmpeg Code nicht Threadsafe und läuft irgendwann in ein Problem. Je mehr Threads parallel abgearbeitet werden können, desto größer ist die Wahrscheinlichkeit, in so ein Problem zu laufen, weshalb es beim i7 eher auftritt als beim i5. Bei einem modernen Treadripper mit 24 Kernen und 48 Threads dürfte das Problem sogar noch viel eher auftreten.

Dann wunderts mich allerdings, dass hier keiner sagt „hab ich auch schon beobachtet / gehört“. Schließlich dürfte ffmpeg ziemlich breit im Einsatz für so was sein, entweder direkt in der shell wie ich es am liebsten mache oder unter der Haube grafischer NL-Editoren.

Ich wusste z.B. nicht, ob die Software bei parallelen Tasks selbst ihre Threads sauber auseinanderhalten muss oder ob sich darum der Scheduler und/oder das OS kümmert.

Daher schiebe ich die Schuld lieber weiterhin auf meine Hardware, die ja nur für Office-Zwecke konzipiert wurde. Da reicht vermutlich eine kleine Schwäche in einer Abschirmmaßnahme (Masseführung oder sonstwas), schon kippt nach zwei Stunden Dauerlast mal ein Bit in der Speicheradressierung und der Salat ist da (in meiner zugegeben laienhaften Vorstellung, bin zwar Ingenieur, aber weder Software- noch Hardwareexperte).

--ks

[MSfree]

Dann wunderts mich allerdings, dass hier keiner sagt „hab ich auch schon beobachtet / gehört“

Dann wirf mal "ffmpeg not thread safe" in die Suchmaschine deines geringsten Mißtrauens.

Schließlich dürfte ffmpeg ziemlich breit im Einsatz für so was sein

Naja, ich nutze ffmpeg alle paar Monate mal um irgendeine Datei umzukodieren. Ob das dann immer multithreaded ist, beobachte ich in der Regel nicht.

Ich wusste z.B. nicht, ob die Software bei parallelen Tasks selbst ihre Threads sauber auseinanderhalten muss oder ob sich darum der Scheduler und/oder das OS kümmert.

Multihtreading innerhalb der selben Anwendung ist noch um so vieles komlizierter als du denkst. Da muß man beim Programmieren aufpassen wie ein Luchs, um sich nicht selbst ein Bein zu stellen. Das OS und der Scheduler können sich nicht um Abhängigkeiten innerhalb des Codes kümmern, das muß man zu Fub ausprogrammieren.

Wenn ich z.B. in einem Programm eine Datei offen habe und ein Thread will gerade ein paar Byte von einer Stelle der Datei lesen, ein zweiter Thread will aber gleichzeitig an der selben Stelle was schreiben, wer hat Recht? Wie soll das OS und/oder der Scheduler das bestimmen?

Daher schiebe ich die Schuld lieber weiterhin auf meine Hardware

Das sehe ich nach deinen Schilderungen aber völlig anders.
Wenn es dir möglich ist, ein Beispiel mit Daten zu konstruieren, mit dem der Absturz zuverlässig provozierbar ist, dann würde ich das als Bubreport mitsamt der Daten einreichen, damit sich das jemand ansehen kann.

[kreuzschnabel]

Danke für deine Erläuterungen. Ich korrigiere also zu: Ich bleibe bei der Hardwarekonfiguration, in der es zufriedenstellend läuft

Ein Szenario zur reproduzierbaren Provokation des Fehlers habe ich nicht, das bleibt wohl dem Zufall überlassen, möglicherweise sind es ja solche Simultanzugriffe wie du beschreibst. Daher kann ich wohl nur wenig Konstruktives zum Debugging beitragen.

[kreuzschnabel]

Ultimativer Nachtrag zum endgültigen Nachtrag:

Das Umkodieren mit ffmpeg läuft (bis jetzt) auch mit dem i7 unfallfrei, wenn ich mit

Code: Alles auswählen

-threads 2

die Anzahl der Frame-Threads begrenze. Zuerst hat mich dabei verwirrt, dass nach wie vor alle 8 virtuellen Cores des i7 ausgelastet werden und die Meldung "Thread pool created using 8 threads" erscheint. Doch entscheidend scheint die Anzahl der „frame threads“ darunter zu sein:



Da erscheinen per default beim virtuellen 8-Kerner 3, mit dem Parameter nur 2, und damit scheint es stabil zu laufen oder zumindest nur sehr selten den beschriebenen Fehler zu werfen. Ich habe den Eindruck, es läuft sogar etwas schneller.

Damit kann ich perfekt leben. Danke fürs Mitdenken!

--ks

[MaGe]

[...] Ich habe den Eindruck, es läuft sogar etwas schneller.

Frage interessehalber, wie hoch ist die cpu auslastung bei normal ohne, und mit threads 2



gruss MaGe

[kreuzschnabel]

wie hoch ist die cpu auslastung bei normal ohne, und mit threads 2

In etwa gleich. Wenn nur ein Task läuft, bei 75 % (CPU gesamt, also Durchschnittswert, mehr oder weniger gleichmäßig auf alle acht verteilt).



Laufen zwei oder mehr Instanzen von ffmpeg mit unterschiedlichen Jobs gleichzeitig, sind wir bei 100 %. Auch mit beiden Einstellungen.

--ks

[MaGe]

Danke!
Das bestätigt meine eigenen tests.

https://imgur.com/a/SP6biIt



gruss MaGe