vdr-plugin-restfulapi verursacht 100% CPU Last

  • Hallo,


    ich jetzt dem Thread auf die Spur gekommen, der hier Amok läuft:


    Leider hat der Thread keinen Namen. Aber mit gdb und attach 2609 konnte ich folgenden Backtrace entlocken


    Code
    (gdb) backtrace
    #0  0x00007faed35f4c5e in FileNotifier::Action() () from /usr/lib/vdr/plugins/libvdr-restfulapi.so.2.0.6
    #1  0x000000000050d92d in cThread::StartThread (Thread=0x7faed385da10) at thread.c:262
    #2  0x00007faee3f3de9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
    #3  0x00007faee297573d in clone () from /lib/x86_64-linux-gnu/libc.so.6
    #4  0x0000000000000000 in ?? ()


    Ich habe jetzt herausgefunden, dass der Thread immer abstürzt, wenn der remove deleted recordings thread gestartet wird.


    Der komplette Aufruf sieht so aus:
    -Prestfulapi --port=8002 --ip=0.0.0.0 --epgimages=/var/cache/vdr/epgimages --channellogos=/usr/share/vdr-channellogos


    Also noch mal genau ins Syslog geschaut


    Und in der Tat /usr/share/vdr-channellogos gibt es in meinem System gar nicht. Und beide Verzeichnisse sind leer.


    Aber auch nach Erstellen des Verzeichnisses und reinkopieren jeweils einer PNG und JPG Datei bringen das gleiche Verhalten.


    Ich werde demnächst mal ein paar Debugausgaben einbauen.


    Vielleicht hat vorher noch jemand eine andere schlaue Idee.



    Tschüß Frank

  • Mini73 gab mir den Tipp für das Debuggen vdr-plugin-restfulapi-dbg zu installieren.


    Also habe ich mich das erste mal mit GDB versucht.


    Damit war die Stelle des Problems schnell lokalisiert: FileNotifier::Action (this=0x7f8ba861da10) at tools.cpp:259
    Der inotify_event sieht hier so aus:

    Code
    inotify_event
    __s32 wd;     = 1                   /* watch descriptor */
    __u32 mask;   = IN_ISDIR+IN_DELETE  /* watch mask */
    __u32 cookie; = 0                   /* cookie to synchronize two events */
    __u32 len;    = 32                  /* length (including nulls) of name */
    char name[0]; = images              /* stub for possible name */


    Und diese Whileschleife wird nie beendet, weil i nie erhöht wird:

    Code
    while ( i < length ) {
                 struct inotify_event *event = ( struct inotify_event * ) &buffer[ i ];
                 if ( event->len > 0 && !(event->mask & IN_ISDIR) ) {
    ...
                    i += EVENT_SIZE + event->len;
                 }
              }


    Woher kommt das jetzt erst?
    In epgimages habe ich seit EpgD die Unterverzeichnisse movies und series mit über 44000 Images in weiteren Unterverzeichnissen.
    Wenn eine Aufnahme gelöscht wird, werden dort irgendwann images gelöscht:


    Erstmal könnte man die Erhöhung von i (oben Zeile 5) zwei Zeilen tiefer setzen, damit Verzeichnisse ignoriert werden. Ob es sinnvoll auch die Unterordner durchzugehen kann ich nicht beurteilen, weil ich nicht übersehe wofür und wo restfulapi genutzt wird.


    Ich vertraue da mal ganz auf Lars. ;D


    Wundert mich ein bisschen, dass noch niemand sonst dieses Problem aufgefallen. Aber bei mir habe ich es auch nur gemerkt, weil ich einen Intel boxed Lüfter verbaut habe, der bei 100% Last denn doch mal hörbar wird.



    Tschüß Frank

  • Hier noch der Patch:

  • Ja, das Hochzählen von i sollte dringend zwei Zeilen tiefer wie im Patch, da spricht überhaupt nichts gegen.


    hepi, machst du das (falls du gerade an einem passenden Rechner sitz)? Sonst mach ich das nachher, spätestens heute Abend.


    Lars.

  • Super! Der Commit sollte dann per cherry-pick nach testing-0.5 und stable-0.5.
    In master scheinen ja noch ein paar Dinge zu sein, die vielleicht noch nicht nach stable sollen, oder?


    Lars.

  • Hallo,


    toll, dass ihr so schnell tätig werdet. Da hätte ich mir das patchen ja fast schenken können.


    Aber ich kann nun bestätigen, dass das Problem damit bei mir Geschichte ist.


    Tschüß Frank

  • immer wieder schön wenn ein Fehler weniger ist


    muss unbedingt mal den server neu machen und das debian runter werfen der Maintainer fixed das tntnet nicht weil er meint es gäbe keinen bug :(


    naja das OSD funktioniert bis auf die Farbtasten schon ganz gut / nur die farbtasten werden noch nicht eingefärbt da noch ein fehler in der less datei ist :-/


Jetzt mitmachen!

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