VDR Crash, wenn Abspielen und Stopp einer Aufnahme zu nah bei einander liegen

    Danke, damit ist schon mal der Crash weg, aber er scheint an dem Mutex in der player.c Zeile 111 hängen zu bleiben und reagiert dann weder auf SVDRP-Befehle noch auf sonstige Eingaben:

    Hier noch der Backtrace und die kompletten Logausgaben, wenn ich in gdb die Ausführung des hängen gebliebenen VDR unterbreche:

    vdr-2.4.1-dbg-double-free-index-06.backtrace.txt

    vdr-2.4.1-dbg-double-free-index-06.full_log.txt

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Damit läuft es leider auch noch nicht rund - mal hängt es in der recording.c:

    vdr-2.4.1-dbg-double-free-index-07.log.txt

    vdr-2.4.1-dbg-double-free-index-07.backtrace.txt


    Oder alternativ in der player.c:

    vdr-2.4.1-dbg-double-free-index-07.log2.txt

    vdr-2.4.1-dbg-double-free-index-07.backtrace2.txt

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich komme voraussichtlich erst am späteren Nachmittag oder heute Abend dazu den Patch auszuprobieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    ..Jehova, Jehova.


    std::string, std::vector, ...



    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Ich habe das jetzt mal mehrere Stunden mit dem letzten Patch laufen lassen und konnte keinen Crash oder Hänger an der Stelle mehr provozieren (lediglich pulseaudio ist da ein paar mal ausgestiegen, wenn das Gerät so schnell geöffnet und geschlossen wird, wenn ich softhddevice dann kein Audiodevice gebe, läuft es lange durch.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Heißt das, mit dem gleichen Patch ohne Logging gibt es Probleme, mit Logging aber nicht? Das würde bedeuten, dass das Problem eigentlich noch nicht gelöst ist.


    Der shared_ptr hätte den Vorteil, dass man für die Nutzung natürlich noch ein Lock bräuchte, aber keiner muss sich um ein delete kümmern, weil einfach der letzte es automatisch machen würde. Das geht natürlich nur mit "delete", nicht mit "free".

    Zitat von mini73

    Heißt das, mit dem gleichen Patch ohne Logging gibt es Probleme, mit Logging aber nicht? Das würde bedeuten, dass das Problem eigentlich noch nicht gelöst ist.

    Zwischen den beiden letzten Patches gab es ja noch mehr Änderungen als Logmeldungen in die Mutex-Klasse einzubauen - aber ich kann das gerne mal ohne die Debug-Ausgaben in cMutex::Lock und cMutex::Unlock versuchen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Jeder Test ist gut. Aber wenn es noch andere Änderungen gab (ich hab die Patches nicht verglichen), ist's ja gut. Ich hab den Post nur anders interpretiert.

    Durch den Einbau des Loggings für cMutex habe ich gesehen, dass ControlMutexLock den Lock über den Aufruf von Interface->GetKey() gehalten hat, was normalerweise 1 Sekunde dauert. Also viel zu lange für einen Lock. Das habe ich bei der Gelegenheit dann in zwei Locks aufgeteilt.

    seahawk1986 soll ich den gesamten Patch nochmal ohne diese Änderung posten, oder kannst du das selber machen? Der Test wäre natürlich gut.

    Ich hatte die dsyslog-Zeilen in den beiden Methoden mal auskommentiert, der Patch sieht damit so aus: vdr-2-4-1-dbg-double-free-index-08-modified.diff


    Das ganze ist jetzt knapp eine Stunde gelaufen und gerade hatte ich einen Crash mit einem SIGPIPE-Signal:

    vdr-2.4.1-dbg-double-free-index-08.no-mutex-log.log.txt

    vdr-2.4.1-dbg-double-free-index-08.no-mutex-log.backtrace.txt

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Das sieht für mich nicht so aus, als wenn das mit dem aktuellen Problem zu tun hätte.

    Beim Zugriff auf cControl fehlte eindeutig ein Lock. Hier sehe ich aber keinen fehlenden Lock.

    Thread 9 hat offensichtlich einen Read-Lock auf die Recordings, und Thread 1 wartet auf den Write-Lock.

    Auch im Log-File ist nichts ungewöhnliches zu sehen.


    Wie wollen wir jetzt weiter machen? Soll ich einen Patch ohne alle Debug-Ausgaben machen und du lässt damit deinen Stresstest weiter laufen, um zu sehen, ob das cControl-Problem noch auftritt bzw. dieses neue Problem erbeut auftritt?

    Zitat von kls

    Wie wollen wir jetzt weiter machen? Soll ich einen Patch ohne alle Debug-Ausgaben machen und du lässt damit deinen Stresstest weiter laufen, um zu sehen, ob das cControl-Problem noch auftritt bzw. dieses neue Problem erbeut auftritt?

    Können wir gerne so machen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Anbei der "aufgeräumte" Patch. Beim Aufräumen ist mir noch aufgefallen, das ich bei


    - if (!cControl::Control()) {

    + if (Control) {


    und

    - if (!cControl::Control() && !cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {

    + if (Control && !cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {

    versehentlich das '!' gelöscht hatte. Das ist in diesem Stand wieder drin.

    Des weiteren ist mir aufgefallen, dass in cMenuMain::Update() der Lock unnötig lange gehalten wurde. Ist hier auch geändert.
    Und schließlich habe ich noch die anfangs eingefügte Zeile


    + index = NULL;


    in recording.c wieder entfernt. Das war der erste Ansatz bei der Spurensuche, darf aber nicht nötig sein, da wir uns hier ja im Destruktor befinden und dieses Member danach nicht mehr angesprochen werden kann.


    Bitte schaut auch selber nochmal kritisch über den Patch drüber, nicht dass mir noch ein Leichtinnsfehler unterlaufen ist.

    Der letzte Patch sieht gut aus, der VDR ist jetzt gut 4 Stunden ohne Crash und Hänger mit dem Stresstest gelaufen und mit der VueJS-Komponente, mit der mir das Problem ursprünglich aufgefallen ist, kann ich auch keinen Crash mehr provozieren.


    Wenn das ein guter Zwischenstand ist, würde ich das mal Pakete in einem PPA bauen lassen, damit ich das im regulären Betrieb besser testen kann.


    Da ich den Weg über SVDRP ursprünglich als Workaround für Hänger mit dem dbus2vdr-Plugin gegangen bin (das Plugin läuft regelmäßig in einen Deadlock, wenn man eine Aufnahme abspielen lassen will, während bereits eine Wiedergabe läuft - https://github.com/flensrocker…b/master/recording.c#L202 , Backtrace: dbus2vdr_play_rec-deadlock.txt) - wie sollte denn jetzt idealerweise der Code in einem Plugin aussehen, das eine Aufnahmen abspielen will?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Gefällt mir 1

    So lange nicht cControl::Control() verwendet wird, ist keinerlei Änderung erforderlich. In dem Code des dbus2vdr-Plugins unter deinem Link oben ist dies nicht der Fall, also von daher kein Handlungsbedarf.


    Ich werde dann nach einiger Testzeit in meinem Alltags-VDR den aktuellen Stand mit diesem Patch als Version 2.4.2 freigeben.

    Und falls dbus2vdr doch noch blockiert, ist es vermutlich selbst schuld...


    Es sieht ja danach aus, als ob cControl::Shutdown nicht zurück kommt. Wenn bei dbus2vdr Requests reinkommen, werden die meist parallel abgearbeitet. Vielleicht überholt es sich da noch etwas selbst und blockiert dann was in cControl. Ich bin da jetzt aber auch nicht mehr so stark drin im Code, da muss ich erst mal wieder lesen...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden