[skinlcarsng] segfault in displaymenu.c (gelöst)

  • Hallo kamel5,


    ich habe hier folgenden segfault:


    Taucht auf mit folgendem Szenario auf:

    - skinlcarsng.DispInfoMenuTimer ist gesetzt

    - Die Timer werden auf dem Server gesetzt

    - Das Event ist zwar in der epg.data des Servers enthalten, fehlt allerdings in der epg.data auf dem Client, da der Client die epg.data über streamdev "nachzieht"

    - Wenn ich die epg.data vom Server auf den Client kopiere, passt es.


    Schnelle Lösung:

    oder die events aus der epg.data des Systems lesen, von der auch die timers.conf stammt. Ich weiß aber nicht, ob man da ans client-server handling von VDR selbst ran müsste.

    Die Abfrage gegen !Event wäre imho immer sinnvoll, da die epg.data ja zwischendurch auch mal bereinigt werden kann und die timers.conf bleibt trotzdem...


    Gruß

    Andreas

  • Danke!


    Ich habe noch was gefunden:


    Code
    Mai 22 16:49:56 rockchip1 vdr[956]: [956] currentBase:  Aufzeichnungen (256:00 frei), Base:  Aufzeichnungen (256:00 frei), p:  Aufzeichnungen (256:00 frei), n: 0
    Mai 22 16:49:56 rockchip1 vdr[956]: [956] orig path: /storage/videos
    Mai 22 16:49:56 rockchip1 vdr[956]: [956] tmpbase: _Aufzeichnungen_(256:00_frei), path: /storage/videos/_Aufzeichnungen_(256:00_frei)
    Mai 22 16:49:56 rockchip1 vdr[956]: [956] Error while getting filesystem size - stat (/storage/videos/_Aufzeichnungen_(256:00_frei)): No such file or directory
    
    
    Mai 22 16:50:34 rockchip1 vdr[956]: [956] currentBase:  Harry Potter (256:00 frei), Base:  Harry Potter (256:00 frei), p:  Harry Potter (256:00 frei), n: 0
    Mai 22 16:50:34 rockchip1 vdr[956]: [956] orig path: /storage/videos
    Mai 22 16:50:34 rockchip1 vdr[956]: [956] tmpbase: _Harry_Potter_(256:00_frei), path: /storage/videos/_Harry_Potter_(256:00_frei)
    Mai 22 16:50:34 rockchip1 vdr[956]: [956] Error while getting filesystem size - stat (/storage/videos/_Harry_Potter_(256:00_frei)): No such file or directory

    Das passiert, wenn ich durch das Aufzeichnungsmenü gehe und 1) den ersten Ordner und 2) einen Unterordner ansteuere. Die jeweils ersten drei Zeilen kommen von diesem Patch, den ich vorher drauf losgelassen habe:

    Ich habe das Gefühl, dass das so nicht ganz gewollt ist...

    Ich bekomme nämlich hier auch einen segfault in libarmmem-v71.so (https://github.com/bavison/arm-mem). Wenn ich es richtig verstehe, wird das in LibreELEC dafür benutzt, bestimmt string-Funktionen mit NEON zu beschleunigen. Leider bekomme ich keinen vernünftigen Backtrace, der mir den Ursprung preisgibt...

    Code
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0xf79b0a64 in memcpy () from /usr/lib/libarmmem-v7l.so
    [Current thread is 1 (Thread 0xdd670400 (LWP 5158))]
    (gdb) bt full
    #0  0xf79b0a64 in memcpy () from /usr/lib/libarmmem-v7l.so
    No symbol table info available.
    #1  0x00000158 in ?? ()
    No symbol table info available.
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

    Da ich das noch nie mit anderen Skins hatte, habe ich jetzt mal skinlcarsng im Verdacht und evtl. auch einen Zusammenhang mit dem Problem oben...


    Gruß

    Andreas

  • Nachtrag: Ich habe da noch den hide_first_recording_level patch mit drin, der in die recording.c schreibt. Ich teste nochmal ohne...

  • So wie es aussieht (tmpbase: _Aufzeichnungen_(256:00_frei) nutzt Du extrecmenung. Dann ist diese Fehlermeldung in Zeile 4 OK (den Pfad mit angehängter Größe gibt es ja sonst nicht. Damit keine Fehlermeldung erzeugt wird, solltest Du in den Einstellungen von extrecmenung "Freien Speicherplatz anzeigen" auf "Nein" stellen.


    Um festzustellen, ob es tatsächlich an dieser Funktion liegt kannst Du folgende Änderung mal testen:

    Code
    int FreeMB(const char *Base, bool menurecording)
    {
    //  if (!menurecording)                                <- auskommentieren
         return cVideoDiskUsage::FreeMinutes();

    Dann sollte diese Funktion nur den Standardwert zurückgeben.


    Dieser Teil:

    Code
         const char *p = strchr(currentBase, ' ');
         if (p) {
            int n = p - currentBase;
            if (n == 3 || n == 6) {
               strshift(currentBase, n + 1);
               }
            }

    hat etwas mit den wareagleicons zu tun (das hat aber auch Nebenwirkungen), da ist mir allerdings bisher nichts besseres eingefallen. Da bin ich für jede Idee offen.


    Du kannst aber auch die Version 0.3.7 von LCARSNG mal testen. Da wurde es an dieser Stelle noch anders behandelt.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Bin einen Schritt weiter. Der segfault passiert nicht, wenn ich das originale Aufzeichnungsmenu verwende.

    Mir ist aufgefallen, dass beim extrecmenung " Aufzeichnungen", d.h. mit vorangestellten Leerzeichen, als currentTitle kommt, das Original liefert "Aufzeichnungen" zurück. Daher gibts auch die Unterstriche... Mal sehen, was ich herausfinden kann.

    "Freien Speicherplatz anzeigen" habe ich deaktiviert.

  • Mir ist aufgefallen, dass beim extrecmenung " Aufzeichnungen", d.h. mit vorangestellten Leerzeichen

    Das ist die richtige Stelle:

    Da müsste das Leerzeichen, in Anhängigkeit von den Icons hin.


    Also z.B. so:

    Code
         SetTitle(cString::sprintf("%s%s%s",
                                   hasmovecopy ? Icons::MovingRecording()
                                               : hascutter ? Icons::Scissor()
                                                           : "",
                                   (hasmovecopy || hascutter) ? " " : "";
                                   base ? base
                                        : delRecMenu ? tr("Deleted Recordings")
                                                     : trVDR("Recordings")));

    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Danke, hatte es schon gefunden. Aber das war nicht der Grund für den SEGV. Ich muss mir die libarmmem nochmal ansehen. Mich macht am bt stutzig, dass vdr* da gar nicht auftaucht...


    Gruß

    Andreas

  • Danke, hatte es schon gefunden.

    Kein Problem.

    Ich werde diese Änderung in myMenuRecordings::Title() aber trotzdem in die nächste Version mit übernehmen, das hat mich auch schon länger gestört, das da ein Leerzeichen ohne vorhandene Icons eingefügt wird.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Danke. Und wenn du schon dabei bist, kannst du hier auch noch gegen !Info prüfen ;)


    Gruß

    Andreas

  • gegen !Info prüfen

    Das schadet sicher nichts, wenn ich den Core-VDR aber richtig verstanden habe, dann kann Recording->Info() nie NULL sein. Im Core-VDR wird das z.B. auch nicht geprüft :)

    Oder könnte das tatsächlich vorkommen.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Bei mir hats da vorhin gekracht. Bin mir nicht mehr sicher, ob extrecmenung dabei war, aber das spielt da glaub ich nicht rein.

    Die recording.h ist auch im bt aufgetaucht, allerdings weiß ich die Zeile nicht mehr sicher, ich glaub http://git.tvdr.de/?p=vdr.git;…ecdd9cd3d4b19;hb=HEAD#l86 wars.

    Evtl. kann es sein, dass event hier NULL sein kann? Dann bringt die Abfrage auf !Info nichts und man müsste vorher ein GetEvent prüfen.

    Ich bin da jetzt nicht tief eingestiegen, aber wenn meine Theorie stimmt, dann wäre im VDR core evtl. nachzubessern? kls ?

    Gruß

    Andreas


    EDIT: Ich glaube, event kann nicht NULL sein http://git.tvdr.de/?p=vdr.git;…3a46e1a1fdc3;hb=HEAD#l362 ;)

  • Ob da beim Core VDR noch was passieren kann, kann ich im Moment auf die Schnelle auch nicht sagen.

    In skinlcarsng gibt es an dieser Stelle:

    Code
      } else if (aI.Event) {
         Event = aI.Event;
         if (!Event->Description())
            return;

    kein Problem, da aI.Event schon in cLCARSNGDisplayMenu::Flush überprüft wird, und cDrawDescription in diesem Fall nur dann erzeugt wird, wenn aI.Event nicht NULL ist.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • EDIT: Ich glaube, event kann nicht NULL sein http://git.tvdr.de/?p=vdr.git;…3a46e1a1fdc3;hb=HEAD#l362 ;)

    Das sehe ich mittlerweile auch so.

    Damit sollte auch das:

    Code
         if (Info->GetEvent()->ParentalRating())
            parentalRating = Info->GetEvent()->GetParentalRatingString();

    kein Problem sein. Mhh...


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Meinen SEGV habe ich mittlerweile auf mesa zurückführen können:

    So wie ich das sehe möchte irgendwer da was mit der Breite 0 anlegen, woraus dann das anschließende memcpy wohl nicht zurecht kommt. Wo das her kommt und warum das mesa nicht abfängt, weiß ich noch nicht. Ich schiebe es erstmal auf einen Bug in mesa. Aber eventuell lässt sich ja das Gebilde mit Breite 0 finden...


    EDIT: Die Abmessungen von box passen imho nicht mit size zusammen. Wenn pipe->buffer_map Speicher in der Größe von box reserviert, also 0, dann kann das memcpy nicht klappen...

  • EDIT: Die Abmessungen von box passen imho nicht mit size zusammen. Wenn pipe->buffer_map Speicher in der Größe von box reserviert, also 0, dann kann das memcpy nicht klappen...

    width = 0 kann eigentlich nicht gewollt sein. Die Frage ist halt, wo das her kommt. Da die meisten Werte dynamisch erzeugt werden, wird das schwer werden... Möglicherweise mit einer Menge Debug-Ausgaben.

    Da die Werte vor allem von der Font-Größe (VDR-Einstellungen-OSD) Standard-Schriftart und Kleine Schriftart abhängen,

    würde ich da mal Änderungen machen. Du könntest auch mal im skinlcarsng Setup den Rand ändern.

    Vielleicht verhält es sich dann schon anders.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Das muss eine Pixmap sein, aus der dann ein texture wird. Ich kann das im output device abfangen bzw. debuggen.

    Anfangsverdacht: Es fehlt irgendwo die Abfrage nach der maximalen pixmap Größe. Size ist ja nicht so klein...

  • Wenn es eine Pixmap ist sollte es zu finden sein. Es gibt in displaymenu.c nur in cDrawDescription diese 3 Pixmaps:

    BackgroundPixmap, BracketPixmap, TextPixmap. Deren Größe ist allerdings auch dynamisch.

    Die max. Pixmap Größe frage ich im Moment nicht ab.

    In allen anderen Funktionen wird direkt ins OSD geschrieben.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich glaube, ich habs gefunden. Liegt am Ausgabeplugin.

    Also entweder kommt ein leerer oder ein NULL-string zu DrawText und damit geht es dann falsch um. Den Bug hab ich selbst eingeführt :rolleyes:


    Unabhängig davon stellt sich mir die Frage, von wem und warum DrawText einen leeren String bzw. NULL-string bekommt und wofür das Sinn macht?

    Edited once, last by rell ().

  • Ich habe gerade mal geschaut, wo es einen leeren Text in cDrawDescription geben kann (ich gehe davon aus, das der segfault dort passiert). Es gibt da eigentlich nur eine Stelle, die anfällig sein könnte.

    Du könntest mal den angehängten Patch testen, der sollte das abfangen.


    Grüße

    kamel5

Participate now!

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