segfault beim Start von VDR auf OSS11.4 64Bit

  • HW: TT S2-6400
    OS: OSS 11.4
    VDR 1.7.19
    PLUGINS: dvbhddevice und remote


    Compiliert, beim ersten Start lässt sich die FB anlernen, danach beim richtigen Start kommt immer ein segfault:



    Hat jemand eine Idee?
    Kann es daran liegen, dass die Eingänge der Karte nicht angeschlossen sind?
    Ich hätte eine schwarzes Bild mit funktionierendem Menü erwartet.


    Grüße
    Walter

  • Hat jemand eine Idee?


    Die locales machen evtl. Ärger ... einfach mal export LC_ALL=de_DE.UTF-8 vor dem VDR Start setzen

    Kann es daran liegen, dass die Eingänge der Karte nicht angeschlossen sind?
    Ich hätte eine schwarzes Bild mit funktionierendem Menü erwartet.

    auch möglich, aber ich würde erst beim Start einer Aufzeichnung einen (kontrollierten) Ausstieg (Emergency Exit) erwarten.
    Oder beim Anlernen ist was schief gegangen (weil die letzte Meldung "remote control remote-ir - keys known" ist), kann mir aber nicht vorstellen was.

  • Hallo,


    das war's leider nicht.
    Die LC_ALL Variable steht mit im Startskript, remote-Plugin und remote.conf sind i.O.
    Der segfault kommt sofort, ohne Verzögerung.


    Harte Nuss, hat noch jemand eine Idee :-(?

  • Was sagt denn strace? Könntest Du evtl das Startup-Script temporär so modifizieren, dass der vdr mit

    Code
    strace -o <output_file> vdr ...

    gestartet wird? Das File könnte etwas größer werden, also irgendwo ablegen, wo genug Platz ist. Sollte das nicht helfen, wäre ein backtrace nicht verkehrt...

    cu -HD-

    VDR1 (stable),
    yavdr 0.3: POV330 ION, 3GB, OCZ Vertex2 60GB, DD Octopus 1xDuoFlexS2

  • Habe weiter erfolglos probiert.


    Aktueller /var/log/messages:


    Ein strace Mittschnitt:


    MSG_NOSIGNAL ....
    Kann es daran liegen, dass ich kein Signal angeschlossen habe?

  • Hi Walter,


    hm, was mich irritiert sind die Zugriffe auf die devices in /dev/dvb/... Kannst Du bitte mal überprüfen, welche Adapter unter /dev/dvb/ da sind und welche devices in den Adaptern angelegt wurden (also alles was mit frontend, ca, osd uws anfängt)?
    Des weiteren gibts laut strace ein paar files nicht, wie z.B. das /etc/vdr/setup.conf. Ich kenne mich im vdr-Code nicht gut aus, daher weiss ich nicht, in wie fern fehlende Files ihn aus dem Tritt ringen.
    Schau mal das strace-Log nach open() calls durch, die mit ENOENT zurück kamen und versuche mal, die Files anzulegen (evtl findest du ja irgendwelche Samples). Sollte das alles nicht weiterhelfen, würde ich mich mal ein backtrace nach dem segfault interessieren. Doch dazu morgen ...ähh... heute mehr...
    Bis nachher.

    cu -HD-

    VDR1 (stable),
    yavdr 0.3: POV330 ION, 3GB, OCZ Vertex2 60GB, DD Octopus 1xDuoFlexS2

  • HW: TT S2-6400
    OS: OSS 11.4
    VDR 1.7.19


    VDR 1.7.19 ist nicht zu empfehlen, da er einen gravierenden Bug enthält.


    Zitat


    PLUGINS: dvbhddevice und remote


    Compiliert, beim ersten Start lässt sich die FB anlernen, danach beim richtigen Start kommt immer ein segfault:


    Zunächst würde ich memtest laufen lassen, um einen HW-Defekt auszuschließen.


    Zitat
    Code
    Jun 22 00:05:19 vdr vdr: [7802] VDR version 1.7.19 started
    Jun 22 00:05:19 vdr vdr: [7802] switched to user 'vdr'
    Jun 22 00:05:19 vdr vdr: [7802] codeset is 'ANSI_X3.4-1968' - unknown
    Jun 22 00:05:19 vdr vdr: [7802] found 0 locales in /usr/local/src/vdr/locale


    Mit den Lokales ist etwas faul. Wie ist die Environmentvariable "LANG" eingestellt?


    Zitat
    Code
    Jun 22 00:05:19 vdr kernel: [ 3412.010437] vdr[7802]: segfault at 0 ip 00000000004fa622 sp 00007fff7c63ee78 error 4 in vdr[400000+161000]


    Mit gdb einen Backtrace machen.


    Zitat


    Kann es daran liegen, dass die Eingänge der Karte nicht angeschlossen sind?
    Ich hätte eine schwarzes Bild mit funktionierendem Menü erwartet.


    VDR 1.7.18 hat kein Problem, wenn kein Signal anliegt. Nicht getestet mit 1.7.19.


    CU
    Oliver

  • Also am fehlenden Signal liegt's nicht - habe beide Eingänge mit Signal versehen.


    Es werden folgende devices vom Treiber bereitsgestellt:


    Ist dies bei euch auch so? adapter1 hat weniger devices?

  • Hi Walter,


    schau Dir bitte mal an, mit welchen Parametern der VDR im startup-Script aufgerufen wird. Dann stellst Du sicher, dass kein vdr-Prozess mehr läuft. Von der Commandline startest Du jetzt den vdr im gdb wie folgt:

    Code
    gdb --args vdr <rest_der_parameter>


    gdb ist interactiv, d.h. Du bekommst nun eine "gdb-shell", in der Du Commands gegen den Debugger absetzen kannst. Den Prozess kannst Du nun starten mit "r". Sobals er auf den segfault läuft, bleibt er stehen und akzeptiert wieder eine Eingabe. Jetzt forderst Du mit "bt" einen backtrace an und postest den hier mal. Dann müsste man schon ein ganzes Stück weiterkommen.


    BTW: Vorher solltest du den vdr mit Debug-Symbolen (gcc -g ...) neu compilieren.


    [EDIT] typo

    cu -HD-

    VDR1 (stable),
    yavdr 0.3: POV330 ION, 3GB, OCZ Vertex2 60GB, DD Octopus 1xDuoFlexS2

    Einmal editiert, zuletzt von Holger D. ()

  • Hi Walter,


    ich selbst habe keine FFHD-Karte, daher ist ein Vergleich mit meinem System nicht wirklich hilfreich. Aber ich vermute mal, dass der 2. Tuner die Devices anbietet, die normalerweise eine Budget-Karte auch hat. Und die 4 Devices deines 2. adapter, scheinen mir ok zu sein.


    Warum dann im strace die ENOENTs drin sind beim Zugriff auf die devices, ist mir schleierhaft... Kannst Du evtl mal sicherstellen, dass die modules der Karte geladen werden, bevor der vdr startet?

    cu -HD-

    VDR1 (stable),
    yavdr 0.3: POV330 ION, 3GB, OCZ Vertex2 60GB, DD Octopus 1xDuoFlexS2

  • Hallo Holger,


    danke für Deinen Einsatz.
    Die Module werden vom Startskript geladen, ich hänge es nochmal w.u. an.
    Den backtrace habe ich nun gemacht, habe auch in die betroffenen Sourcefiles gesehen, aber es ist (noch) nicht "heller" geworden:

    Code
    (gdb) bt
    #0  isnumber (s=0x0) at tools.c:264
    #1  0x0000000000502962 in main (argc=<value optimized out>, argv=<value optimized out>) at vdr.c:707


    Startskript:

  • !!! Es ist die fehlende setup.conf !!!


    Mit der funktioniert's! Habe die von meinem alten 1.4.X eingespielt ...
    Warum ist eigentlich keine sample-Datei dabei, es werden doch einige andere mitgeliefert?
    Vor allem wenn sie so kritisch ist.
    Wieso bin eigentlich nur ich darübergestolpert, verstehe ich vorerst nicht ...

  • !!! Es ist die fehlende setup.conf !!!


    Mit der funktioniert's! Habe die von meinem alten 1.4.X eingespielt ...
    Warum ist eigentlich keine sample-Datei dabei, es werden doch einige andere mitgeliefert?
    Vor allem wenn sie so kritisch ist.
    Wieso bin eigentlich nur ich darübergestolpert, verstehe ich vorerst nicht ...


    Wenn dem so ist, ist es ein Bug. VDR sollte setup.conf beim ersten Start anlegen.


    CU
    Oliver

  • Vom Quelltext her startet VDR auch ohne setup.conf, erlegt dann ein Objekt der Klasse cSetup an mit den Defaultparametern und würde es (spätestens) beim Beenden speichern. Insofern glaube ich nicht, dass es an der fehlenden setup.conf lag, sondern an einem anderen Effekt, der durch einen fehlenden Parameter ausgelöst wurde.....


    Weitere Analyse: der SEGV passiert in vdr.c:707, was erst in 1.7.19 dazu gekommen ist:

    Code
    if (isnumber(Setup.InitialChannel)) { // for compatibility with old setup.conf files

    Da muss wohl noch ein zusätzlicher Check rein .... ich schicke es mal an Klaus ...

  • Hi Walter,

    (gdb) bt
    #0 isnumber (s=0x0) at tools.c:264
    #1 0x0000000000502962 in main (argc=, argv=) at vdr.c:707

    na, da haben wir ja auch schon den Schuldigen... isnumber() wird hier mit einem Null-Pointer aufgerufen. Der Check am Anfang der Methode sollte den Pointer überprüfen, nicht den value.


    Ich hänge hier mal einen Patch an und ich fände es prima, wenn Du den mal ausprobieren könntest (also mal testen ohne setup.conf). Ich werde parallel Klaus ne Mail schicken.

  • Sorry Leute, bin erstmal froh, dass es überhaupt funktioniert.
    Habe schon an Klaus gemailt, bitte ihn nicht mit Mails fluten.


    Warten wir doch mal ab, was der Meister sagt.

Jetzt mitmachen!

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