restfulapi: SIGSEGV, Segmentation fault

  • Da ich nicht auf den Bugtracker komme und auch im Github irgendwie keine Möglichkeit finde, einen Issue zu melden, versuche ich es hier.


    Installiert ist die aktuelle Git-Version des Plugins (0.2.5.5).


    Aufruf mit http://<server>:<port>/info.json Resultat ist ein SIGSEGV und ein Neustart des bzw. der entsprechenden VDR Instanzen (mit oder ohne DVB devices, streamdev server oder client):


    Der BT sieht so aus:


    Ich denke, ich werde die nächsten Tests nicht mehr mit den Produktions-VDR machen 8)


    Zabrimus

  • Hi,


    hast du noch weitere Infos zur Umgebung? VDR Version usw.

    Grüße


    Hannemann

  • Kein Problem.


    VDR Version ist in allen Fällen ein VDR 2.2.0. Passiert ist es auf folgenden Systemen:


    1. Debian Jessie, 8 DVB Devices, Streamdev Server (headless)
    2. Debian Jessie, 0 DVB Devices, reiner Streamdev Client (headless)
    3. Raspbian, 0 DVB Devices, reiner Streamdev Client (TV)


    Der Softwarestand aller Server/Client ist (endlich) identisch, die Hardware ist schon relativ unterschiedlich.


    Das Plugin will wohl den Channelname lesen oder verarbeiten. Dann könnte evt. das Plugin suspendoutput mit eine Ursache sein - reine Mutmaßung.


    Zabrimus

  • Klingt plausibel...


    Zabrimus : kannst du das bitte mal testen?

    Grüße


    Hannemann

  • So endlich Zeit gefunden...


    Eine einfache Bedingung reicht tatsächlich aus, den Segfault zu verhindern:


    Dev-VDR1 ohne Patch stürzt reproduzierbar ab, Dev-VDR2 (1:1 Kopie von Dev-VDR1) mit Patch macht keine Probleme.


    Zabrimus

  • Cool... Vielen Dank.


    Ich wollte auch schon längst einen Patch erstellt haben, bin aber noch nicht dazu gekommen.


    Verdammtes Weihnachten ;)

    Grüße


    Hannemann

  • Hi zusammen,


    habe ein ähnliches Problem. Beim Aufruf von


    http://<server>:<port>/recordings/.json bzw. http://<server>:<port>/recordings.json


    stürzt VDR mit einem Segfault ab:


    vdr: [16954] restfulapi: requested recording not found (read)
    kernel: [5761865.121185] vdr[16954]: segfault at 6900000065 ip 00007f0469362730 sp 00007f044dff0ac0 error 4 in libgcc_s.so.1[7f0469353000+15000]


    Verwende ebenfalls vdr-2.2.0 und die aktuellste Plugin Version aus git 0.2.5.5


    Der SegFault passiert, sobald auch nur ein einziges recording vorhanden ist.. wenn das video.00 VZ leer ist, kommt diese korrekte Antwort:


    {"recordings":[],"count":0,"total":0}


    Hat jmd. ne Idee?


    Viele Grüße

  • Kannst du einen richtigen Backtrace erzeugen? Welche Version von tntnet und cxxtools nutzt du? Ich meine vor der 2.2.0 gab es Probleme mit dem Unicode-Handling.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Version von tntnet ist: 2.1-2.9
    Version von libcxxtools: 2.1.1



    Versuche das mit dem Backtrace gerade hinzubekommen (hab ich noch nie gemacht, muß ich gestehen ?( )


    1.) Versuch:
    ulimit -c unlimited
    vdr ohne -d gestartet
    Fehler provoziert:
    *** stack smashing detected ***: /usr/local/bin/vdr terminated
    Speicherzugriffsfehler (Speicherabzug geschrieben)


    ABER: Finde nirgendwo den core, weder im aktuellen, noch im /tmp Verzeichnis


    2.) Versuch:
    vdr ohne -d gestartet
    gdb --pid <vdrpid>
    continue


    Fehler provoziert
    Im GDB:


    Was mach ich noch falsch?

  • Hab gerade die cores gefunden... waren umgelenkt nach /var/tmp/core :wand


    gdb drauf los gelassen, aber wirklich viel kam dabei auch nicht raus:

  • Sieht für mich trotz fehlender Debug-Symbole nach dem bekannten Unicode-Problem aus - vgl. Restfulapi-Plugin und ein paar Posts vorher. Am einfachsten wäre der Gegentest mit der aktuellen Version der Bibliotheken.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Jups, scheint so, hab die betr. Zeile auch gerade gesehen...


    Das mit dem aktualisieren ist so ne sache.. auf der Kiste läuft neben dem VDR noch einiges mehr und ist ne Distri auf Debian Wheezy Basis... da würde ja auch die komplette libc upgedatet werden müssen... ob das gut geht...

  • Vielen Dank fürs Schubsen hier hin.


    Habe gerade - wie dort angegeben - die Orignalquellen der cxxtools-2.1.1 gepatcht, ein neues .deb gebaut und installiert. Ein erster Test mit einem recording im video.00 Verzeichnis hat schon mal geklappt, kein SegFault mehr...

  • da würde ja auch die komplette libc upgedatet werden müssen

    Eigentlich nur cxxtools, tntnet und die davon abhängigen Pakete - also vermutlich live und restfulapi. IIRC hatte hier schon mal jemand gepostet, dass er den Debian Paketmaintainer gefragt hat, ob er das Paket für wheezy aktualisieren würde, aber der wollte nicht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Eigentlich nur cxxtools, tntnet und die davon abhängigen Pakete - also vermutlich live und restfulapi. IIRC hatte hier schon mal jemand gepostet, dass er den Debian Paketmaintainer gefragt hat, ob er das Paket für wheezy aktualisieren würde, aber der wollte nicht.

    Wenn ich mir das hier so ansehe, sind unter anderen auch die libc zu aktualisieren... die Versionen der abhängigen Pakete sind in Wheezy definitiv kleiner, als dort gefordert.


    However, ist dank dem kleinen Patch der 2.1.1er Version der cxxtools ja zum Glück nicht erforderlich, funktioniert damit jetzt alles bestens.