[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

  • Hallo *,


    seit dem gestrigen Debian Testing Update bekomme ich folgendes:


    Dec 20 06:38:58 debt21 kernel: [ 9104.672990] EPGSearch: conf[7810]: segfault at 1000018 ip 00007fd71d87720d sp 00007fd7190a1a50 error 4 in libvdr-epgsearch.so.2.4.0[7fd71d826000+fc000]

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Failed with result 'signal'.

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Service RestartSec=100ms expired, scheduling restart.

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Scheduled restart job, restart counter is at 5.

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Start request repeated too quickly.

    Dec 20 06:38:58 debt21 systemd[1]: vdr.service: Failed with result 'signal'.


    Idee? / Workaround?


    Dank und Gruss

    klak

  • Hi, eine Ergängzung, der timer conflict check verursacht wohl das Problem:

    Code
    1. Dec 20 09:08:43 debt21 vdr: [3635] EPGSearch: timer conflict check started
    2. Dec 20 09:08:43 debt21 kernel: [ 1764.364601] EPGSearch: conf[3635]: segfault at 1000018 ip 00007fce3cc3920d sp 00007fce23ffea50 error 4 in libvdr-epgsearch.so.2.4.0[7fce3cbe8000+fc000]
    3. Dec 20 09:08:43 debt21 systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV
    4. Dec 20 09:08:43 debt21 systemd[1]: vdr.service: Failed with result 'signal'.


    Kann ich den deaktiveren?

  • Ach sieh an ... den hab ich auch (im Aufnahmen-Sortier-Thread gcc 8.2 / glibc 2.28 kurz erwähnt):

    Backtrace dazu wäre:



    Läuft derzeit auf Custom Kernel 4.19.9, gleich .11 ;)


    Programstelle wäre:

    VDR-Log (Absturz beim Start):

    Code
    1. vdr: [29291] timer 0 (115 1340-1515 'Westworld') set to event Di. 01.01.2019 13:55-15:00 'Westworld'
    2. vdr: [29291] EPGSearch: search timer update finished
    3. vdr: [29291] EPGSearch: check for timer conflicts
    4. <segfault>
    5. vdr: [29337] VDR version 2.4.0 started


    Stefan

  • klak : Sicher kann man den automatischen Konfliktcheck deaktivieren im epgsearch-Setup.

    Dank an Stefan für den Backtrace. Dieser Codeteil ist zur 2.4 nicht angefasst worden. Mich würde interessen, wie zum Absturzzeitpunkt die Werte von it, *it und checkTime sind. Und vielleicht vor einer Reproduktion das epgsearch-Logging aktivieren

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • TomJoad :


    Das muß dem jüngsten Buster glib oder gcc-8.2 Update zusammen hängen. Davor lief epgsearch auch mit 2.4. problemlos. Hab schon bis auf eine Objektkopie alle Warnungen beseitigt, aber das Problem ist mir unklar...


    Macht man die vier Zeilen raus, läuft der Konflikcheck wieder. Mit bekomme ich den VDR nicht mehr hoch.


    Für gcc 8.2.12 hab ich derzeit folgendes drin:


    Sowie:


    Und:



    Die Warnung muß noch:


    Code
    1. blacklist.c: In member function 'cBlacklist& cBlacklist::operator=(const cBlacklist&)':
    2. blacklist.c:105:43: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class cBlacklist' with no trivial copy-assignment; use copy-assignment instead [-Wclass-memaccess]
    3. memcpy(this, &Blacklist, sizeof(*this));
    4. ^
    5. In file included from blacklist.c:26:
    6. blacklist.h:32:7: note: 'class cBlacklist' declared here
    7. class cBlacklist : public cListObject
    8. ^~~~~~~~~~


    Half alles nix -> GPF


    Nur abschalten



    Hilft.


    Kann Dir gerne reincompilieren, was Du an Debug-Ausgaben brauchst...


    Stefan

  • Ich hätte den Verdacht, dass er da außerhalb der Grenzen des std::sets zugreift, weil der iterator ungültig wird, wenn man Elemente löscht und danach einfach inkrementiert - wenn ich https://en.cppreference.com/w/cpp/container/set/erase richtig verstehe, müsste man den den Rückgabewert von erase als neuen Wert von it nehmen können (ungetestet):

    Code
    1. for (it = pendingTimers.begin(); it != pendingTimers.end();) {
    2. if ((*it) && (*it)->stop > checkTime->evaltime)
    3. checkTime->startingTimers.insert(*it);
    4. it = pendingTimers.erase(it);
    5. }

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also:
    Mit obigem Fix ist zwar der Segfault weg, aber die manuelle Timerkonfliktprüfung kehrt nicht mehr zurück (-> VDR Restart). Das Problem hat dann wohl auch "Live".

    Nach Auskommentieren geht auch Live wieder. Es braucht eine andere Lösung. ;)


    Stefan

  • Die Änderung von seahawk kann nicht funktionieren, weil da kein erase(it) steht, sondern erase(*it)

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Bei mir mit bionic und gcc-8 habe ich normales Verhalten bei conflict checks

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Hi,


    hab leider nichts zu kompilieren. Ich setze die Debian Testing Pakete ein.


    Das Problem tritt bei einem tagesaktuellen Testing mit 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) auf.


    Bei einer 2. VM (anderer Host) mit einem selbstgebautem 4.16.0-kk1 #1 SMP Fri Jun 15 NICHT.

  • Der uralte Code macht einen erase auf einen Value, nicht auf eine Iteratorposition. Der Rückgabewert ist in dem Fall laut C++-Referenz ein size_type und nicht die nächste Iteratorposition. (Nicht, dass ich den Code wirklich verstehen würde, aber mit erase(*it) hat es bisher immer funktioniert.

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Hi,


    bei mir ist das Problem nicht mehr vorhanden! (!?!?!?!)


    Habe eine 2 Tage alte Sicherung aufgespielt (bei mir ist alles in VMs) und und dann ein apt update + upgrade gemacht und siehe da, der segfault tritt nicht mehr auf.


    Kann das an der Reihenfolge der Update-Einspielungen zu tun haben?


    Dank und Gruss

    klak

  • Tut mir leid wegen der Verwirrung, aber erase(it) und erase(*it) sollten im Ergebnis das gleiche liefern. Ich kann aber nichts nachstellen, weil bei bionic mit g++ 8.2.0 alles funktioniert, auch mit dem Patch von seahawk wird richtig inkementiert.

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Ich denke, ich kann die Sache aufklären. Ich hatte heute denselben Fehler.


    Der Code in conflictcheck.cpp hat definitiv undefiniertes Verhalten. Und erase(it) und erase(*it) sind auch nicht ganz äquivalent. Letzteres sucht unnötigerweise zuerst nach einem wertgleichen Element.


    Der Einwand von seahawk1986 ist korrekt. Nach erase darf nicht mehr auf existierende Iteratoren zugegriffen werden. Der Fix beseitigt das Problem hier reproduzierbar.

    Allerdings ist er nur die halbe Wahrheit. Der ganze Code steckt auf den ersten Blick voller Fehler mit diesem Muster. Die meisten werden wohl nur seltener durchlaufen. Und die Standardbibliothek garantiert ja nicht, dass die Iteratoren immer ungültig werden. Aber eine Optimierung der stdlibc++ ist hinreichend, um das Verhalten zu ändern. Das wiederum bedeutet, je nach System-Unterbau ist das Verhalten unterschiedlich, was zu den Symptomen passt.


    Ich werde mir den Code notgedrungen mal zur Brust nehmen. Aber nicht mehr heute Abend.

  • Hallo zusammen,


    bei mir ist das Problem wieder da, eine alte Sicherung half diesmal nicht, also habe ich epgsearch deinstalliert.


    Gib es eine Alternative für die Autotimer?


    Dank und Gruss klak