vdr crasht - Debug-enabled build für vdr 1.7.21?

  • Hallo,


    ich habe mit meiner yavdr 0.4-Installation ein Problem, vdr stürzt in regelmäßigen Abständen mit folgender Fehlermeldung ab:


    Oct 9 08:28:32 kernel: [11146.413576] section handler[4810]: segfault at 40faca0 ip 00000000040faca0 sp 00007fab1ee9
    c458 error 15


    Da das so nicht besonders aussagekräftig ist, suche ich eine debug-enabled Version von vdr. Gibt es sowas oder muss ich selbst den Compiler anwerfen?


    Danke,
    Sebi

  • ich habe mit meiner yavdr 0.4-Installation ein Problem, vdr stürzt in regelmäßigen Abständen mit folgender Fehlermeldung ab:

    Code
    segfault at 40faca0 ip 00000000040faca0 sp 00007fab1ee9c458 error 15


    Da das so nicht besonders aussagekräftig ist, suche ich eine debug-enabled Version von vdr. Gibt es sowas oder muss ich selbst den Compiler anwerfen?


    Code
    sudo apt-get install vdr-dbg


    Aber die Fehlermeldung die du da zeigst ist aus dem Kernel und nicht aus dem VDR. Ob dir da das Debuggen wirklich weiterhilft?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hmm, im näheren Zusammenhang sieht das so aus:


    Oct 9 08:28:32 dumbledore vdr: [4810] changing pids of channel 408 from 513+513=2:0:0:0 to 513+513=2:0:0:0
    Oct 9 08:28:32 dumbledore kernel: [11146.413576] section handler[4810]: segfault at 40faca0 ip 00000000040faca0 sp 00007fab1ee9
    c458 error 15
    Oct 9 08:28:32 dumbledore vdr-sxfe[4563]: [4942] [input_vdr] Control stream disconnected
    Oct 9 08:28:32 dumbledore LCDd: sock_send: socket write error
    Oct 9 08:28:32 dumbledore init: vdr main process (4552) killed by SEGV signal
    Oct 9 08:28:33 dumbledore init: vdr-frontend main process (4563) terminated with status 1
    Oct 9 08:28:33 dumbledore vdr-crash: vdr exit with signal SEGV . Restarting


    Das betrifft für meine Begriffe jedenfalls Prozess 4810 - also vdr. Oder sehe ich das falsch?


    Sebi

  • Hi,


    ich habe das gleiche Verhalten und der Backtrace ist identisch mit folgenden Beitrag Segfault mit VDR 1.7.21 .
    Auch hier hilft es alle nicht benötigte Kanäle aus der channels.conf zu löschen, leider damit aber auch die Einstellung "Neuen Kanäle und neue Transponder hinzufügen" NICHT zu wählen.... :(


    Betrifft hier Unitymedia NRW mit yaVdr 0.4


    Zum Beispiel waren Kanäle in der channels.conf doppelt:

    Code
    NRW.TV;UnityDigitalTV:554000:C0M256:C:6900:613=2:614=deu@4:618:1831,1722,1801,1838,1835:24111:9999:241:0
    NRW.TV;UnityDigitalTV:129000:C0M256:C:6900:613=2:614=deu@3:618:1831,1722,1801,1838,1835:24111:9999:351:0


    Ebenfalls gab es einen Segfault beim wirbelscan Plugin (Kanalsuche) --> suche aber noch weiter wenn es die Familie zulässt........


    Gruß,
    Chuck

    1- yavdr 0.5 - DVB-C
    1- VDR-1.7.14 - Xine Pugin - XBMC - DVB-C
    2- Activy 300 mit Gen2VDR V2

  • Hallo vdrchuck,


    Unitymedia in NRW kann ich schon mal bestätigen...


    Die channel.conf werde ich mal entsprechend überarbeiten. Beim Durchsehen meiner Logs gibt's ein paar Einträge, in denen der Crash unmittelbar nach "changing pids" aufgetreten ist, betroffen war dann z.B. der obige #408 (TW1). Manchmal steht da aber auch:


    Oct 10 02:06:26 dumbledore vdr: [7373] changing name of channel 305 from 'Bundesliga,;' to 'Sky Bundesliga,Sky Buli;SKY'
    [...]
    Oct 10 02:08:59 dumbledore kernel: [56495.325081] section handler[7373]: segfault at 300000119 ip 0000000000482ac8 sp 00007f9c43c94420 error 4 in vdr[400000+145000]
    Oct 10 02:08:59 dumbledore LCDd: sock_send: socket write error
    Oct 10 02:08:59 dumbledore vdr-sxfe[10389]: [10406] [input_vdr] Control stream disconnected
    Oct 10 02:08:59 dumbledore init: vdr main process (7118) killed by SEGV signal
    Oct 10 02:08:59 dumbledore init: vdr-frontend main process (10389) terminated with status 1
    Oct 10 02:08:59 dumbledore vdr-crash: vdr exit with signal SEGV . Restarting


    Hier erfolgte der Crash über zwei Minuten nach der letzten Änderung der channel-Datenbank.


    Das Signal ist allerdings auch bei mir eher grenzwertig, auf HD-Sendern gibt's bisweilen Klötzchen.


    Sebastian

  • So,


    ich habe gemäß der Empfehlung aus dem anderen Thread die channels.conf bereinigt und UpdateChannels auf "0" gesetzt, gleichzeitig vdr-dbg installiert und in der /etc/default/vdr DAEMON auf vdr-dbg gesetzt. Wenn's nochmal knallt, sollte ich zumindest einen vernünftigen Backtrace erhalten. Ich werde berichten!


    SebiXVI


  • Ruf doch vor dem Start de VDR mal "ulimit -c unlimited" auf. Danach kannst Du mit gdb analysieren, wo der Fehler herkommt und eventuell auch mal an kls melden.


    Hier gibts mehr Infos: http://vdr-wiki.de/wiki/index.php/Gdb

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Ruf doch vor dem Start de VDR mal "ulimit -c unlimited" auf. Danach kannst Du mit gdb analysieren, wo der Fehler herkommt und eventuell auch mal an kls melden.


    Hier gibts mehr Infos: http://vdr-wiki.de/wiki/index.php/Gdb

    Naja, Backtrace gibt und wurde auch schön erstellt mit installierten "vdr-dbg"......., der backtrace ist eigenlich identisch mit denen im Beitrag Segfault mit VDR 1.7.21 --> wo es schon einen möglichen Fix gibt.


    Nur denke ich, das Klaus dies gerne mit einem Vanilla VDR gestestet haben möchte und das dies mit yavdr 0.4 (Paketverwaltung) nicht so einfach geht (?), ausser die Source Pakete ohne Patche zu installieren.......

    1- yavdr 0.5 - DVB-C
    1- VDR-1.7.14 - Xine Pugin - XBMC - DVB-C
    2- Activy 300 mit Gen2VDR V2

  • Moin,


    nein, bisher gab's noch keinen Backtrace. Ausdünnen der Channels.conf und UpdateChannels=0 hat nichts gebracht. Mein vdr stützt noch immer in unregelmäßigen Abständen ab. Der Backtrace ergibt:



    Jetzt habe ich erstmal meine /var/cache/vdr/epg.data gelöscht, mal sehen was das bringt.


    Sebi

  • Danke hotzenplotz,


    das hatte ich schon gefunden und habe auch schon einen Backtrace erstellt, s.o.


    Allerdings passen zum einen meine Quellen nicht zum Backtrace - eine eit.c mit Zeile 558 bzw. 406 gibt es hier nicht, die Datei hat nur 404 Zelen.


    Außerdem habe ich den Patch aus dem Thread Segfault mit VDR 1.7.21 probieren wollen. Nachdem vdr compiliert wurde, habe ich die vdr-dbg durch die neu kompilierte Version ersetzt. Leider mögen dann die Plugins nicht mehr und beschweren sich über "unknown symbols". Muss ich tatsächlich unbedingt alle Plugins neu installieren? Anders herum (nur Plugins bauen und in /usr/lib/vdr installieren) funktioniert es doch auch?!


    Gerade aktuell sind die Crashs auf einem absoluten Höhepunkt, mehr als 10min sind nicht drin. Das war die letzten Tage anders, da kam es maximal alle paar Stunden zu einem Neustart.


    Sebi

  • Code
    if (Schedules)
                   cEIT EIT(Schedules, Source(), Tid, Data);
                else {


    558 zwischen if else


    Code
    //to avoid double epg-entrys from ext and int epg sources :EW
          if (pEvent && pEvent->TableID() != 0x00)
          {
            cEvent *pPreviousEvent = (cEvent *)pSchedule->GetPreviousEvent(pEvent);


    zeile 404 if (pEvent ... usw.



    gut möglich das es in einem patch ist.
    wenn du in den sourcen suchst musst du die patches darauf anwenden.


    also dpatch apply-all
    dann findet man auch zele 404 bzw. 558

  • Moin,


    Code
    #0 0x00000000004a7300 in cEvent::TableID (this=0x3000000c9) at epg.h:104


    Der this-Zeiger auf das Event sieht gar nicht gut aus... Irgendwas scheint den zu zerschießen.


    Lars.

  • Moin!


    Der meiste Code aus dem Backtrace ist aus dem disableDoubleEpgEntrys-Patch, das heißt aber nicht, das er zwingend dafür verantwortlich ist, dass die events-Liste in cSchedule zerschossen wird.
    Das könnte auch was anderes sein. Vielleicht eine Race-Condition in der Liste? Von wo aus darf AddEvent/DelEvent ausgerufen werden, gibt's da Beschränkungen? Weiß da jemand was?


    Lars.

  • Irgendwie stehe ich auf dem Schlauch - ich finde das Source-Paket nicht?! Lt. aptitude ist das source-Paket des installierten Paketes "vdr" vdr?! Das yavdr-testing-PPA habe ich hinzugefügt. Fehlt mir noch was?


    Sebi

  • Moin!


    Das steht in deinen apt-Sourcen (irgendwo)?

    Code
    deb-src http://ppa.launchpad.net/yavdr/testing-vdr/ubuntu natty main


    Und dann sudo apt-get update und apt-get source vdr gemacht?
    Bei mir hat's (allerdings mit unstable) vorhin noch funktioniert.


    Lars.

  • Ahhhh...kaum macht man's richtig, schon funktionierts. Ich hatte nach einem vdr-source o.ä. gesucht, apt-get source war's, was mir fehlte.


    Danach und einem dpatch apply-all im Sourceverzeichnis konnte ich meinen vdr bauen und die vdr-dbg in /usr/bin ersetzen, ohne alle Plugins neu zu compilieren.


    Sebi

  • Der meiste Code aus dem Backtrace ist aus dem disableDoubleEpgEntrys-Patch, das heißt aber nicht, das er zwingend dafür verantwortlich ist, dass die events-Liste in cSchedule zerschossen wird.
    Das könnte auch was anderes sein. Vielleicht eine Race-Condition in der Liste? Von wo aus darf AddEvent/DelEvent ausgerufen werden, gibt's da Beschränkungen? Weiß da jemand was?

    Der Patch ist es wohl nicht: ich habe mal spaßenshalber den Patch opt-38-disableDoubleEpgEntrys-Patch entfernt (patch -p1 -R). Die Abstürze bleiben, tauchen lediglich an anderer Stelle auf:


    bzw. alternativ



    oder auch:


    Code
    #0 skipspace (s=0x25 <Address 0x25 out of bounds>) at tools.h:194
    194 if ((uchar)*s > ' ') // most strings don't have any leading space, so handle this case as fast as possible
    #0 skipspace (s=0x25 <Address 0x25 out of bounds>) at tools.h:194
    #1 isempty (s=0x25 <Address 0x25 out of bounds>) at tools.c:249
    #2 0x0000000000480d41 in cEvent::Dump (this=0x7f680ac15010, f=0x7f680accf090, Prefix=0x4fd04f "", InfoOnly=false) at epg.c:450
    #3 0x00000000004828e0 in cSchedule::Dump (this=<value optimized out>, f=0x7f680accf090, Prefix=0x4fd04f "", DumpMode=dmAll, AtTime=0) at epg.c:1067
    #4 0x0000000000482b24 in cSchedules::Dump (f=0x7f680accf090, Prefix=0x4fd04f "", DumpMode=dmAll, AtTime=0) at epg.c:1228
    #5 0x0000000000482cd3 in cSchedules::Cleanup (Force=<value optimized out>) at epg.c:1189
    #6 0x00000000004e2e7d in main (argc=<value optimized out>, argv=<value optimized out>) at vdr.c:1375


    Irgendwas scheint also die epg-Daten zu zerschießen, wobei ich epg.data gestern gelöscht hatte, trotzdem tauchten die Abstürze auf.


    Seltsam ist auch, dass gestern abend - nach dem Löschen der Daten - die Abstürze nahezu im 10min-Takt auftraten. Heute hingegen ist "gespenstische Ruhe" und der vdr läuft seit mehreren Stunden. Kann es sein, dass irgendwo in den epg-Daten ein defekter Datensatz enthalten ist, der zum Absturz führt? Nur - wie finde ich den? Wenn vdr abstürzt, wird die epg.data nicht geschrieben, die Daten liegen bis dahin nur im Speicher.


    SebiXVI

Jetzt mitmachen!

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