Posts by horchi

    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.

    Okay selbes Resultat also an den beiden Instanzen des Python Wrapper liegt es schon mal nicht.


    m.E. wird (sofern es am epghttpd liegt, wovon ich ausgehe) etwas im Speicher überschrieben.

    Komisch ist nur das Valgrind dazu nichts anzeigt.


    Hast du mal versucht es mit FORTIFY oder Stack Protection übersetz? Ggf bringt das Licht ins Dunkel

    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?

    beta danke für die Erläuterungen, ich habe mir mit CoreElec hier ein ähnliches Setup zusammengestellt damit läuft der VDR auch wie geschmiert. Das verwende ich immer wenn der Odroid nur oder fast nur für den VDR da ist.

    Bei dem Setup um welches es mir gerade geht ist der VDR nur ein kleiner Teil am Rande. In diesem Szenario habe ich ein paar Dinge welche ich im chroot nicht zum laufen bekomme und andere welche recht umständlich sind. Daher wäre es super wenn ich es unter Plain Ubuntu hinbekomme. Aktuell habe ich es mit apt-mark hold linux-odroid-n2 gelöst, nun kann ich einen Update machen und es läuft immer noch.

    habe gerade die Situation mit Kernel 4.9.337, im log kommt dieser Block an Meldungen 2-3 Mal /Sekunde:

    helfen die weiter, habt ihr eine Idee in welchem Bereich das Problem liegt?

    VDR lässt sich nicht mehgr beenden, auch nicht mit kill -9, es bleibt ein defunct hängen: root 8884 3281 3 16:16 pts/1 00:01:25 [vdr] <defunct>

    ich habe ein lokales DVB Device welches ich verwende wenn ich unterwegs bin - also der normal Betrieb.
    Wenn das Wohnmobil zuhause im Hof steht schaue ich da drin kein TV außer zum testen, dann verwende ich streamdev mit Verbindung zum streamdev Server zuhause da es im Hof mit dem Ausrichten der Schüssel auf dem Wohnmobil etwas knapp ist am Dach vorbei zu kommen.

    In beiden Betriebsarten läuft es mit 4.9.277 stabil und mit 4.9.337 bleibt es nach einiger Zeit hängen - zum Teil erst nach Stunden, je nachdem wie viel ich zappe oder wie oft ich den VDR Starte/Stoppe.

    der Patch läuft wie du es beschreibst, das zu schnell laufen (und ab und zu kurz ruckeln) nach dem zappen ist weg, der Ton kommt damit bei mir gleichzeitig mit dem Bild. Das Bild steht hier dann noch kurz (deutlich unter einer Sekunde) dann läuft alles flüssig.
    Finde es damit angenehmer beim Zappen!

    ja ich habe wieder die aktuelle Plugin Version.
    DVB kann ich ausschließen da es sowohl mit den lokalen DVB Treibern passiert als auch beim Betrieb über streamdev.

    Die Box ist dann noch komplett ansprechbar und alles andere funktioniert dann noch einwandfrei. Nur der VDR läuft erst wieder (bzw. bringt erst wieder Bild) wenn ich gebootet habe.

    Ist es ein amlogic-Problem auf der Dekoderseite

    Woran erkenne ich das bzw. wie kann ich das eingrenzen - vor allem wenn es eins von beidem ist hilft dann diese Informatiuon um ggf. etwas dagegen zu tun?


    CoreELEC mit Ubuntu in einer chroot-Umgebung habe ich im Wohnzimmer da verwende ich der Odroid ausschließlich für den VDR das läuft super stabil.

    Auf dem Odroid im Wohnmobil wird der VDR nur nebenbei verwendet, seine Hauptaufgabe dort ist eine Art Haussteuerung für alle mögliche Hardware und Geräte welche dort verbaut sind. Das alles in chroot ist mir zu frickelig und umständlich. Scheiterte bei meinen Versuchen schon an der dbus Verbindung zum systemd des CE.


    Den Patch kann ich gern testen - ich vermute das er nur mit den Umschaltzeiten zu tun hat und keine Auswirkung/Verbesserung zu dem Problem unter 'pain' Ubuntu?

    okay das scheint auch zu funktionieren :]

    Verständnisfrage, muss man nach der Installation von dem im ersten Post hier genannten Ubuntu 20.04 Image sicherstellen das kein Update gemacht wird oder zumindest der Kernel dabei nicht aktualisiert wird? (Ich meine nicht den update auf 22.04, ... sondern nur die Aktualisierung innerhalb der 20.04).