segfault von epghttpd beim Speichern von Timern

  • Hallo zusammen,


    nachdem epghttpd nun startet (s. [Solved] epghttpd mit Problemen beim Start (Kubuntu 24.04)), ist das Speichern von Timern nicht möglich. Dabei ist es egal, ob neue Timer oder beim Ändern eines Timers.

    Ich bin jetzt erneut ratlos, ob dies an epghttpd liegt, oder an der libpython Version von Ubuntu 24.04. Konnte bisher nur so weit schauen, dass der Backtrace immer "gleich" aussieht, unabhängig davon, ob ein neuer Timer angelegt wird, wie viele Timer bereits existieren, ob ich einen bestehenden Timer ändere ... habe gedacht, dass ggfs. sonst der Paramter size bei _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) mal mit einem anderen Wert als 28 belegt sein würde ... size=28.

    Ein tstate=0x0 sieht auch nicht so richtig gesund aus?!

    Vielleicht hat jemand ähnliche Probleme (gehabt) oder sonst eine Idee, ob es wirklich ganz tief im System verbuddelt ist, oder "nur" an der Übergabe des Timers in die von epghttpd verwendeten Bibliotheken:



    Vielen Dank im Voraus und beste Grüße,

    Chriss

  • Ich antworte mir mal selber:

    Durch Zufall habe ich gerade bemerkt, dass Timer erfolgreich ohne Segfault gespeichert werden, wenn diese bei "Ermittlung des Dateinamens" den Wert "VDR" gesetzt haben. Alle anderen Werte führen zum Absturz.


    Sieht so aus, als sei dies tatsächlich auf den Aufruf der recording.py zurückzuführen... aus der Hilfe von epghttpd:

    Quote

    Der Dateinamen wird, mit Ausnahme des Mode 'VDR', über das Python Skript (/etc/epgd/recording.py) ermittelt, er kann bereits Pfadangaben erhalten.

    • 0 VDR: Keine Ermittlung des Dateinamens, die Bezeichnung der Aufnahme wird dem VDR überlassen lediglich das unten angegebene Verzeichnis wird vorangestellt.
    • 1 Auto: Automatische Auswahl des Mode Constable, Serie oder Kategorisiert
    • 2 Constable: Dateinamen basierend auf Daten von Constabel (Titel/Staffel/xTeil-Nummer/Untertitel) sofern verfügbar
    • 3 Serie: Serienaufnahme ohne Verwendung der Constabel Daten (Titel/Untertitel)
    • 4 Kategorisiert: Einorden der Aufnahmen entsprechend der Film-Kategorie (Kategorie/Titel)
    • 5 User: Hier kann man sich selbst im Python Skript verewigen
    • 6 Template: Der Dateiname wird in Eingabefeld unten definiert, hierbei können Platzhalter (%...%) verwendet werden. Bei Eingabe von % erscheint die Auswahl der Platzhalter

    recording.py macht ein import event, was wohl nicht funktioniert, da eine entsprechende Code-Datei nicht zu finden ist.

    Wie dies zu beheben ist, weiß ich zwar noch nicht, aber ich habe nun zumindest einen Workaround.

    Edited 2 times, last by theonlychriss ().

  • Kannst du mir den BT posten bitte.

    Welche VDR Version?

  • Hi Horchi,


    meinst du den Coredump?

    Sehr gerne, habe ein paar anzubieten und sie am Issue in github hochgeladen.

    Wegen der Dateinamensrestriktionen musst du vermutlich die eine umbennen (".zip entfernen"), um die beiden Zip-Teile entpacken zu können.


    VDR ist 2.6.7


    Danke schon bis hierher und viele Grüße,

    Chriss

  • Ein core dump passt in aller Regel nur zu dem System, der Programm Version, libs etc. mit welchen er entstanden ist.

    Daher bitte einfach nur der (ASCI) BT (Back Trace) hier posten. Ich hoffe das ich damit sehe wo es klemmt.

  • Sorry !!!! ich sehe gerade das hast du oben im ersten Post schon dabei, habe es am Handy übersehen.

    Ich sehe es mir an wenn ich wieder zuhause bin.

  • Habs mir angesehen, leider bis jetzt noch nichts gefunden. Wenn ich mir einen Timer Namen über das Skript erstellen lasse bekomme ich:

    Code
    Jun  4 15:20:12 gate epghttpd: Info: The recording name (mode=4) calculated by 'recording.py' is 'Spielfilm~Nachtschicht: Es lebe der Tod'

    Auch valgrind zeigt mir nichts auffälliges.
    Kannst du es bei dir auch mal mit valgrind laufen lassen?

    Welche python Version verwendet du, also von welcher Version ist das 'dev' Paket installiert?

    Edited once, last by horchi ().

  • Danke horchi!


    Seltsam, dachte es sei ein generelles Problem, weil ich die recording.py halt auch so nicht (on-the-fly) compiliert bekomme (gibt keine recording.pyc).

    Oder ich hab' ein Brett vor'm Kopf?!...

    Code
    chriss@HTPC:/etc/epgd$ python recording.py 
    Traceback (most recent call last):
      File "/etc/epgd/recording.py", line 27, in <module>
        import event
    ModuleNotFoundError: No module named 'event'


    Ich frage mich halt, woher das event kommen soll, wenn nichts im gleichen Verzeichnis liegt, oder auch sonst im Quellcode nicht:

    Code
    chriss@HTPC:/usr/local/src/vdr-git$ find ../vdr-epg-daemon-httpd.git/ -name "event*"
    ../vdr-epg-daemon-httpd.git/http/src/js/eventDetail.js
    ../vdr-epg-daemon-httpd.git/configs/eventsview-uti.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsviewplain-3po.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsviewplain.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-horchi.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-ck.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-3po.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-perlbo.sql


    Python ist 3.12.3-0ubuntu, s. Screenshots


    Vielleicht ist es ja schon etwas sehr Simples, was du daraus siehst.


    Oder hier die Ausgabe beim Crash mit valgrind:


    Viele Grüße,

    Chriss

  • Ich frage mich halt, woher das event kommen soll, wenn nichts im gleichen Verzeichnis liegt, oder auch sonst im Quellcode nicht:

    Das event-Modul kommt aus dem C++ Code: https://github.com/horchi/vdr-…/master/lib/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-…/master/lib/python.c#L223), wird man von außen nichts davon sehen.


    Kannst du mal die Debug-Pakete für Python installieren (python3-dbg und libpython3-dbg und die Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das event-Modul kommt aus dem C++ Code: https://github.com/horchi/vdr-…/master/lib/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-…/master/lib/python.c#L223), wird man von außen nichts davon sehen.

    Habe mir schon gedacht, dass ich etwas übersehe. Danke für die Erklärung!


    Kannst du mal die Debug-Pakete für Python installieren (python3-dbg und libpython3-dbg und die Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?

    Mache ich, sobald ich wieder an den Rechner komme.

  • ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
    oder Failed to load ... ?

  • Bzw. welche Meldungen kommen bei Start nach Initialize python script?

  • Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?

    Bin bis dort kurz davor gekommen und laufe beim apt-get update in diesen issue und muss wohl warten, bis das behoben ist:

    Bug #1975865 “Hash and size mismatch with http://ddebs.ubuntu.co...” : Bugs : apt package : Ubuntu
    When adding the debug repos, I am getting: E: Failed to fetch http://ddebs.ubuntu.com/dists/bionic-updates/main/binary-amd64/Packages.gz File has unexpected…
    bugs.launchpad.net


    ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
    oder Failed to load ... ?

    Nein, nicht zu sehen.


    Bzw. welche Meldungen kommen bei Start nach Initialize python script?

    Habe mal den hoffentlich relevanten Part vom epgd-Start, sowie epghttpd-Start rausgesucht (bei epgd gibt es die Zeile einmal, bei epghttpd doppelt!?):


    Noch eine Frage:

    Verstehe ich es richtig, dass auch bei erfolgreichem "Durchschleusen" der event Datenstruktur aus dem C++ Kompilat ins python-Modul, keine .pyc erzeugt wird?


    Danke euch beiden fürs Dranbleiben und viele Grüße,

    Chriss

  • Bin bis dort kurz davor gekommen und laufe beim apt-get update in diesen issue und muss wohl warten, bis das behoben ist:

    Eventuell reichen die Debug-Pakete für Python schon, da scheint ja irgendetwas nach dem Aufruf von PyObject_CallObject schiefzugehen, also wo er aus dem C++-Code eine Python-Funktion aufruft.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • So, heute ließ sich das Repository der debug-Symbole ansprechen und ich habe das einzige Paket, das ansatzweise danach aussieht, installiert:


    Der BT sieht nicht anders aus?!

    Dasselbe mit valgrind laufen lassen ergibt diesmal eine sehr lange Textdatei, s. Anhang valgrind.zip valgrind.zip.

    Ehrlich gesagt, verstehe ich nun nicht, warum darin kein bisschen von der libmicrohttp die Rede ist...


    Viele Grüße,

    Chriss

  • pull mal die neuste Version aus dem git, wechsle in den lib Ordner und baue das pytst:

    Code
    cd lib
    make pytst

    dann aufrufen (./pytst) und entsprechend der Usage Ausgabe verwenden.
    Damit kannst du des Python Skript Aufruf aus dem c++ Code heraus testen. Wenn das geht liegt das Problem an anderer Stelle. Wenn es nicht geht müssen wir viel weniger Code debuggen.

  • Hi horchi,


    danke vielmals für das mini-How-To. Resultat ist:

    Code
    $ ./pytst "tvm" "S19.2E-1-1107-17501" 191051494 1
    20:57:13,346  Info: Calling mysql_library_init()
    20:57:13,346  Calling mysql_init(14130)
    20:57:13,347  SQL client character now 'utf8mb3'
    20:57:13,347  Event 'Die Simpsons/Angst essen Seele auf' found
    20:57:13,347  Initialize python script '/etc/epgd/recording.py'
    20:57:13,367  Result of call: Die Simpsons~17x02 - 358. Angst essen Seele auf
    20:57:13,367  Info: The recording name calculated by 'recording.py' (with namingmode 1) is 'Die Simpsons~17x02 - 358. Angst essen Seele auf'
    20:57:13,370  Info: Released the last usage of mysql_lib, calling mysql_library_end() now
    20:57:13,370  Closing mysql connection and calling mysql_thread_end(14130)

    Weiß jetzt nur nicht, ob ich das gut oder schlecht finden soll :saint:


    Viele Grüße,

    Chriss

  • zumindest wissen wir nun das der Python Aufruf aus C++ funktioniert. Der Code dazu welchen der epghttpd verwendet ist der selbe.
    Entweder etwas rundrum, zum Beispiel das der epghttpd zwei Instanzen davon verwendet oder ein ganz anderer Fehler welchen den Speicher vorher schreddert.

    Vielleicht als nächstes die andere Stelle mal auskommentieren und schauen was dann passiert.

    Edited once, last by horchi ().

  • Versuchs mal hiermit:

    Ist nur ein Test um es einzugrenzen, keine Lösung. Dden epgd würde ich damit nicht tauschen nur den ephghttpd sonst hebelst du auch dort das generieren der Namen aus.

  • Merci horchi!


    Habe epghttpd nach deiner Vorgabe neu gebaut und die Executable davon benutzt ...


    Hat für mich erkennbar nur eine Sache geändert, nämlich, dass die Zeile Initialize python script '/etc/epgd/recording.py' nur einmal kommt:


    Und dies habe ich bisher noch nicht gesehen, scheint mir aber eine ganz andere Baustelle und somit Zufallsfund zu sein:

    Code
    2024-06-10T18:40:38.003433+02:00 HTPC epghttpd: webif: TypeError: t.find(...)[0] is undefined$line: 1$column: 100433$error: loadData/<@http:/192.168.0.10:8888/epgd.js?1.3.24:1:100433$i@http://192.168.0.10:8888/common.js?1.3.24:2:27151$fireWith@http://192.168.0.10:8888/common.js?1.3.24:2:27914$z@http://192.168.0.10:8888/common.js?1.3.24:4:12120$send/c/<@http://192.168.0.10:8888/common.js?1.3.24:4:15680$


    Hier noch der bt von der gepatchten Version des epghttpd:

    Bin wieder und weiterhin ratlos.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!