SIGSEGV in cListBase::Sort

  • Hallo zusammen,


    ich bin in folgenden segfault gelaufen. Iirc hatte ich das schonmal, weiß aber nicht, wie ich das reproduzieren kann.

    System ist arm64 mit VDR 2.5.1, softhddevice-drm (mit gles), skindesigner und streamdev-client. Es passierte nachdem ich meine Kanäle durchgeschalten hatte und ungefähr von Kanal 250 wieder auf Kanal 1 (Das Erste HD) schalten wollte.

    Hat einer Idee, ob das am VDR core liegt oder meine Plugins da Ärger machen. Auf den ersten Blick scheint mir was mit VDR's EPG handling nicht zu stimmen.


    Danke und Gruß

    Andreas

  • Ist gerade wieder passiert:

  • Hmm, irgendwas geht bei deinen EPG Einträgen schief, benutzt du einen EPG Import oder native DVB EPG?

  • Wußte ich schon, als ich absenden geklickt hab..


    aarch64 -> RPi@64bit o.ä. ?
    Lösch mal deine epg.data, restarte VDR und versuch nochmal.

  • Was macht VDR hier, bzw. was wird hier "sortiert"? Kann das mit den Plugins überhaupt zusammenhängen?

    Sind das neue Einträge, die hinzugefügt werden sollen, oder was altes? Ich könnte mal die epg.data löschen!?

  • Jup, Allwinner macht hier keinen Unterschied.


    Kein Plugin Problem, denke ich. Problem liegt in vdr, (g)libc oder RAM.

    VDR sortiert wohl gerade den EPG neu, während des EPG update von DVB.


    Mehr kann ich nicht daraus lesen, vllt. gibts ja Xperts mit mehr Infos.

  • Werds weiter beobachten, aber nachdem ich die epg.data gelöscht habe, siehts bisher ganz gut aus. Danke!

  • Irgendwas passt bei mir nicht...

    Irgendwie habe ich das Gefühl, dass was mit meinem EPG nicht passt... Kann das was mit aarch64 zu tun haben? Oder kann das ein Folgefehler sein, nachdem der VDR zuvor schon mal abgeraucht ist? Allerdings hatte ich da kein gdb dabei...

  • Viell. blöde Frage: aber Festplatte voll?

    MyVDR: yaVDR-Ansible (Ubuntu 18) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Nein, auf der Platte sollte genug Platz sein.


    Mittlweile habe ich irgendwie das Gefühl, dass das mit der Architektur zusammenhängt.

    Ich habe einen armhf (Allwinner H3) und einen aarch64 (Allwinner H6) mit - soweit möglich - demselben Softwarestand (Kernel, Debian, VDR etc.) aufgesetzt und habe jetzt in meinem mehrtägigen (Produktiv-)Test der 32bit Platform keinerlei unerwartete Abbrüche oder segfaults. Im Gegenteil, ich bin richtig zufrieden.


    Auf aarch64 hingegen kamen die Dinge oft unverhofft, gefühlt aus dem Nichts. Evtl. ist es auch ein Temperaturproblem, das den H6 "verrückt" spielen lässt!? Aber dann würde ich erwarten, dass sich das System komplett aufhängt und nicht "nur" einen SEGFAULT produziert.

    Ist vielleicht schon etwas zu weit gesponnen und so richtig zu Ende gedacht habe ich es auch nicht, aber könnte es sein, dass es hier irgendwo noch Probleme mit 32bit/64bit gibt? Z.B. irgendwelche Überläufe oder Probleme mit z.B. signed/unsigned long Typen? Aber dann sollte ich doch nicht der einzige sein, der da Probleme hat...


    Falls jemanden etwas einfällt, gerne, ansonsten werde ich jetzt mal weiter beobachten, Logs sammeln und versuchen mein Problem einzugrenzen ;)


    Gruß

    Andreas

  • Hier noch mal ein paar backtraces, die sich vermeintlich "willkürlich" hier so ergeben, vielleicht kann ja jemand was herauslesen. System ist jeweils aarch64, vdr2.5.1, streamdev-client und softhddevice-drm. Ich weiß nicht, wie ich es reproduzieren kann, es kommt einfach. Und das eigentlich ziemlich schnell während des Zappens...



    https://pastebin.com/raw/T6KpnbWS

    https://pastebin.com/raw/tquGMXmv

    https://pastebin.com/raw/grufcyRY

    https://pastebin.com/raw/qjkSvh8i


    Gruß

    Andreas


    EDIT: Auf dem Server habe ich auf diesen Vorschlag hin folgenden Patch mit drin:

    Aber das dürfte doch wohl keine Rolle spielen!?

  • Ob es nicht doch ein Speicherproblem ist? Es sieht mehr danach aus, als ob im RAM ein oder mehrere Bits umfallen und dann mit ungültigen Pointern gearbeitet wird. Dass es meistens in eit.c/epg.c passiert liegt vielleicht daran, das hier mehr RAM benötigt wird und man so in einen fehlerhaften Bereich kommt.

    Starte doch einmal mit den Kernel Parameter memtest=1 (siehe auch: automatically-memtest-and-then-boot )

    LG helmut

  • memtest testet ja immer nur bestimmte Bereiche, oder? Kann ich auch alles checken lassen? Soweit kommt es mir nämlich nicht verdächtig vor.

  • Es werden schon alle Bereiche geprüft auf die memtest Zugriff hat - 0x40000000-0x7fffffff sind 1GiB, die oberen 256 MiB davon sind für cma reserviert. Es sieht aber fehlerfrei aus. Einen ausführlicheren Test macht vielleicht memtest86, direkt vom USB-Stick gestartet.

    Es wäre natürlich gut wenn es nicht am RAM liegt, aber mehr fällt mir dazu im Augenblick auch nicht ein. Der VDR läuft normalerweise auch auf 64-Bit problemlos.

    LG Helmut

  • Ich fürchte, das wird eine schwierige Geburt ;) Ich wäre ja fast schon froh, wenn ein defekter Speicher gefunden würde...

    Ich habe jetzt im laufenden Betrieb memtester laufen. Aber auch hier werden mir bisher keine Fehler angezeigt.


    Was ich nicht verstehe ist folgendes: Der OrangePi One Plus hat insgesamt 1GB Speicher. 256MB sind für CMA reserviert, aber trotzdem werden mir von /proc/meminfo 851,3MB als MemFree und etwas weniger als MemAvailable gekennzeichnet sind. Müsste das maximale MemAvailable/Free (in einer groben Rechnung) nicht 1GB-256MB CMA sein? Außerdem steht bei VmallocTotal 135290159040kB was mir sehr spanisch vorkommt ....


    Gruß

    Andreas

  • Hast du irgendwann Meldungen Out of Memory im Syslog und Frage zwei, hat dein System Swap Space?

  • 1) Ich starte nochmal neu, versuchs zu reproduzieren und schau ins log wegen oom. Aktuell habe ich schon Meldungen drin, aber die kommen wohl vom memtester, weil ich einen zu großen Bereich testen wollte.

    2) Nein, kein Swap, da ich das der SD Karte (noch) nicht antun wollte.


    Gruß

    Andreas