[remote] Plugin-Verwendung beendet VDR

    Ich teste mal auf dem VDR-Client, ob das da auch passiert.

    Wenn ja, ist es wohl ein Codeproblem, wenn nein, eines von meinem VDR-Server.

    So, also - mit VDR 2.6.6 und allen Plugins in den neuesten Versionen bekomme ich folgende Ergebnisse:


    Auf dem VDR-Client (openSUSE Tumbleweed latest snapshot):

    - control funktioniert

    - remote funktioniert


    Auf dem VDR-Server (openSUSE Leap 15.5 latest hotfixes):

    - control crasht

    - remote crasht

    wobei es offenbar zwei verschiedene Stellen sind, an denen die Crashes passieren.


    Dumps siehe Anhänge.

    So wie es ausschaut, crasht dein VDR wegen einem Plugin namens ''epg2vdr", aber nicht im control Plugin.

    Ich kenne das Plugin nicht.


    Das hier sind die Zeilen kurz vor dem Problem:


    So wie es ausschaut, crasht dieses Plugin bei der Verwendung von Texten/Zeichenketten (std::string).

    Das Seltsame ist, dass es zwar in epg2vdr crasht, aber immer nur bei der Benutzung von control (nicht aber von remote).

    Und bei remote ist der Crash ja irgendwo bei der Font-Verarbeitung (nicht aber bei control).


    Und das nur bei einem von zwei VDRs, die beide denselben Stand haben (bis aufs OS).

    So sieht es beim remote Plugin aus.



    Hier crasht es in cFont::SetFont(eDvbFont, char const*, int)

    Der gemeinsame Punkt ist


    Code
    cOsdMenu::ProcessKey

    Installiere doch mal die Fonts auf dem Server, die Du auf dem Client installiert hat.

    Und teste danach nochmal auf dem Server ...

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Hab ich schon, hilft nix - und das ist doch auch nur im einen Fall die Stelle, an der der Dump auftritt.

    Ohne epg2vdr funktioniert control.

    Zitat von wirbel

    Ohne epg2vdr funktioniert control.

    Hm, und was mache ich dann`? epg2vdr brauche ich halt auch.

    Witzigerweise funktionieren control und remote beide ausgerechnet gegen den Client, bei dem ich sie eigentlich nicht brauche, weil er eben nicht headless ist - und der hat auch epg2vdr.

    Zitat von nobanzai

    Hm, und was mache ich dann`? epg2vdr brauche ich halt auch.

    Witzigerweise funktionieren control und remote beide ausgerechnet gegen den Client, bei dem ich sie eigentlich nicht brauche, weil er eben nicht headless ist - und der hat auch epg2vdr.

    ich habe das gefühl das mit der vdr version 2.6.6 ,

    einige plugins probleme haben, restfulapi schmeist segfaults

    osdtelext auch.

    https://www.minidvblinux.de/forum/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 als Client MLD 5.4

    1x Raspberry 2 als Client MLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x Cubietruck

    1x MCC 100
    1x BananaPi

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    Wann passieren diese Crashs eigentlich genau?

    Braucht es irgend eine User-Interaktion dazu?


    Bei den beiden letzten vdr.dump-*.txt sieht es irgendwie so aus, als ob man sich gerade im Menü befindet.

    Genauer gesagt im Setup-Menü von einem Plugin und gerade "Ok" gedrückt wurde.

    Den Zustand hätte ich so jetzt nicht erwartet, das kann aber eine Fehleinschätzung sein, besonders viel mit den Menüs habe ich mich noch nicht beschäftigt.


    Ihr könnt ja mal versuchen raus zu finden, welche Änderung die Fehler auslöst.

    Wenn man das weiß, erleichtert einem das die Suche nach dem Fehler erheblich, weil man ungefähr weiß wonach man schauen muss.

    So viele Änderungen zwischen 2.6.5 und 2.6.6 gab es ja gar nicht, das sollte recht schnell gehen.


    Der aussichtsreichste Kandidat wären für mich nach wie vor:

    Added the move constructor to cString for better performance

    Gruss
    SHF


    Naja, in den Plugins remote und control ist es immer eine Useraktion, weil über die ja vor allem das Menü bedient wird.

    Also ja, immer nach dem Connect und ein paarmal Anwählen von Menüpunkten passiert es.

    Es passiert aber nicht beim Laden des Plugin.

    Wie gesagt - die Dumps hängen an den entsprechenden Postings mit dran.

    Gut, das erklärt, warum er im Menü abstürzt.

    Die Ursache dürfte aber irgendwo "früher" gewesen sein und jetzt nicht mehr zu sehen.


    Das deutet dann auch stark auf den "move construktor" hin.

    Gruss
    SHF


    Ich habe jetzt folgenden Test durchgeführt


    a) vdr-2.6.6 mit epg2vdr und control gestartet

    b) vdr-2.6.6 mit epg2vdr und softhddevice gestartet


    In beiden Fällen stürzt vdr absolut zuverlässig ab, wenn ich im Haupmenü

    'EPG and Timer' und dann auf 'Timer' gehe.


    Der Fehler liegt eindeutig an epg2vdr. Auch der Stack trace sieht gleich aus.

    Hups - bei mir passiert das nur in control und remote und nur auf dem headless Server.

    Auf dem Client klappen remote und control problemlos, obwohl dort ebenfalls epg2vdr (und softhddevice) läuft. Auch im OnScreen Menü am Fernseher kann ich problemlos alles anwählen, auch "EPG und Timer Service".

    Gefühlt haben so einige Plugins mit der 2.6.6 VDR Version Probleme


    restfulapi, osdtelext

    https://www.minidvblinux.de/forum/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 als Client MLD 5.4

    1x Raspberry 2 als Client MLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x Cubietruck

    1x MCC 100
    1x BananaPi

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    EPG2VDR setze ich nicht ein, kenne mich also auch 0 damit aus.

    Kann man das ohne Datenbank überhaupt sinnvoll testen?

    Muss ich da was einstellen?


    osdtelext benutze ich selber und habe es eben mal angetestet. Abstürze bekomme ich aber keine hin.

    Allerdings bekomme ich auch keinen Videotext angezeigt (Seite nicht vorhanden, bitte warten).

    Bislang hatte das immer geklappt, soweit ich mich erinnere. Hab's hin bekommen, war mein Fehler.

    Abstürze gibt es aber immer noch nicht.


    Zitat von wirbel

    In beiden Fällen stürzt vdr absolut zuverlässig ab, wenn ich im Haupmenü

    'EPG and Timer' und dann auf 'Timer' gehe.

    nobanzai hatte die Abstürze aber immer im Einstellungsmenü :/ .

    Evtl. doch was mit dem Menü an sich? Oder das Menü hat gar nichts damit zu tun und ist nur das Opfer.

    Die Crashs waren auch wieder bei einem free(). Das kann doch eigentlich nur bedeuten, dass auch hier was mit dem Pointer nicht gestimmt hat.

    Gruss
    SHF


    Einmal editiert, zuletzt von SHF ()

    Das Einstellungsmenü von epg2vdr ging bei mir in allen Tests ohne Probleme. Seltsam.

    Ich habe es mal mit ElectricFence probiert und da gibt es mit dem EPG2VDR-Plugin beliebig reproduzierbar nach Sekunden einen Abbruch.
    ElectricFence Exiting: mprotect() failed: Speicherzugriffsfehler (Speicherabzug geschrieben)

    Das passiert auch mit dem EPG2VDR-Plugin allein.

    Und auch nur mit dem EPG2VDR-Plugin, nicht mit osdtelext und control.

    Allerdings kann ich den VDR mit ElectricFence nicht mehr von der Konsole bedienen, konnte osdtelext also nicht näher testen. (Bei EPG2VDR komme ich gar nicht so weit.)


    Wer es auch versuchen will, ElectricFence gibt es bei Debian als Paket und es ist recht einfach:

    EF_ALLOW_MALLOC_0=1 LD_PRELOAD=/usr/lib/libefence.so ./vdr -Pepg2vdr ......


    Der Fehler ist immer cSchedule, allerdings an unterschiedlichen Stellen, hier mal ein Beispiel:

    Vom EPG2VDR-Plugin sehe ich hier keinen Thread.

    Das könnte auf den EPG-Handler hindeuten, der wird AFAIK von VDR ausgeführt.



    Das EPG2VDR-Plugin habe ich lediglich mit -Pepg2vdr gestartet.

    Es ist völlig unkonfiguriert und eine Daenbank habe ich auch nicht am laufen.

    Es gibt beim Start auch ein paar Fehlermeldungen:

    Einen Speicherzugriffsfehler sollte das aber eigentlich auf keine Fall nicht auslösen.



    Dann bin ich auf was merkwürdiges gestoßen:

    C++: handler.h
    //***************************************************************************
// Define tEventID again, to create a compiler error case it was defines different
//***************************************************************************

typedef u_int32_t tEventID;     // on error vdr >= 2.3.1 and patch is not applied!!

    In der README steht aber:

    Code: README
    - Patch the VDR. Patches found in patches/ since vdr 1.7.27.
  For Versions after 1.7.31 you need only the epghandler-segment-transfer.patch
  Sinve VDR 2.1.1 no patch is needed!

    Unter /patches liegen auch Patches für vdr-2.2.0 und 2.3.0.

    Was stimmt denn nun :/ ?

    Und der eine Patch für VDR-2.3.0 fummelt ausgerechnet am Schedules- und ChannelsStatekey herum.

    Gruss
    SHF


Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden