Posts by horchi

    was lange währt ....

    Nachdem ich meinen Server auf Ubuntu 24.04 aktualisiert habe ich ich nun auch in den 'Genuss' von libpython 3.12 gekommen.
    So konnte ich es reproduzieren und nach langer Suche beheben. Der Ansatz meines letzten Versuchs via PyGILState_Ensure() / PyGILState_Release war richtig.
    Gefehlt hatte nur noch das Freigeben des Locks welche die Lib automatisch beim Initialisieren für dem Main-Thread anlegt - genau das ist Bescheiden bis nicht dokumentiert (sofern ich nicht ganz blind bin).

    Lange Rede ... mit der neusten epgs/epghttpd Version (1.3.25) im Git sollte das Problem nicht mehr auftreten.

    LG Jörg

    versuche es bitte nochmal hiermit.
    Ich bekomme damit mit Python 3.8 einen Deadlock und vermute es ist der hier beschriebene. Menie Hoffnung ist das es damit mit der 3.12 läuft

    ich hab mir mal die Hinweise zum Thread handing für die Python Lib angesehen und mal Test weise etwas eingebaut (untested!)

    es compiliert, weiter konnte ich noch nicht testen.

    /EDIT: könnt ja mal berichten wenn ihr es damit testen konntet

    habe es mir angesehen, der Umbau ist nicht ganz klein.

    Das Plugin ist so aufgebaut das es eine Event Quelle ist, die DVB Events werden abgegriffen und in einer Datenbank abgelegt, sie gelangen nicht ins EPG. In der Datenbank werden sie mit EPG Daten aus bis zu zwei weiteren EPG Quellen gemerged und damit neue Events erstellt welche auf diesem Weg aktuell gehalten werden. Diese Events werden in das EPG übernommen.

    Das hätte man auch anderes aufbauen können, damals erschien es als best mögliche Lösung, auch zu dem Damaligen Stand des EPG Handler Interfaces.

    Um es nun umzubauen muss das Handling der IDs umgebaut werden, also die Stelle an welcher alles zusammen läuft.

    Ich werde das mal mit CKone durchsprechen ggf. fällt uns eine pragmatische Lösung ein, für einen großen Umbau habe ich im Moment keine Zeit.

    Jup (muss ich eigentlich -fno-stack-protector -O0 aus dem ifdef DEBUG Block auch noch entfernen, weil sich sonst das -O2 und -O0 bzw. die unterschiedlichen stack-protection Optionen beißen?):

    ja, sorry hatte ich übersehen:

    aber wie kommt man nun dem Problem besser auf die Spur?

    Sieht immer noch gleich aus für meine Augen:

    in den Fall hat es wie es aussieht nicht geholfen. Diese Einstellungen bewirken das (in bestimmten Situationen) Stack Fehler, Buffer-Overflows etc. erkannt und direkt mir SEGFAULT abgebrochen wird wodurch man die auslösende Stelle besser eingrenzen kann. Hier hat es wohl nicht zugeschlagen. Das ganze war ausgehend von der Vermutung das der Crash in der Python Lib nur ein Folgefehler ist (wovon ich immer noch ausgehe). Hab gerade auch keine Idee mehr wie man dem auf die Schliche kommen könnte.

    Generell läuft meine Implementierung rund um die Python C++ lib ja, zum einen im epgd und zum anderen auch im Test Programm.

    ja genau. Definiere dir am besten dieses Macro im Make.config

    Code
    CFLAGS_MEM = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS \
                 -fstack-clash-protection -fstack-protector-strong \
                 -Wl,-z,nodlopen -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
    CFLAGS_MEM += -fcf-protection=full -Wtrampolines

    und hänge es an die CFLAGS dran:

    Code
    CFLAGS += $(CFLAGS_MEM) -O2

    dann alles neu bauen

    Code
    make clean
    make 

    beim make solltest du dann sehen das die Optionen verwendet werden

    Als Patch:

    das ist kein Fix hilft aber ggf. um dem Problem auf die Spur zu kommen.

    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.

    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.

    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.

    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?