Bitte um Aufnahme Plugin icetft in yavdr

    Hallo Zusammen,


    ich würde gerne das Plugin icetft zusammen mit yaVDR 0.61 benutzen.


    Ich kriege es leider selbst nicht zum laufen und würde mich sehr über Hilfe freuen.


    Das Icetft ist via USB über eine prolific PL2303 usb2serial Adapter angeschlossen und via udev-Regel auch immer am identischen "Link" und funktioniert auch:


    Ich habe den Quellcode aus der aktuellen gen2vdr Installation benutzt und kriege unter einer "normalen" ubuntuu (16.04) Installation mit dem im Plugin enthaltenen "Komandozeilen" Program "serialtft" das Display an. (In gen2vdr funktioniert auch das Plugin selbst tatellos und ich hatte bisher immer SuSE mit selbstkompilierten VDR, wo es auch funktioniert hat)


    Mit yaVDR kriege ich aber das Display nicht an hier erhalte ich "Speicherfehler" und laut logdate mit dem Komandozeilenprogramm "serialtft":


    "serialtft[1996]: segfault at 4006d0 ip 00007fc9880dd554 sp 00007ffdffed5248 error 7 in libc-2.19.so[7fc988055000+1bb000]"


    Mit kompilieren des Plugins erzeuge ich einen Absturz. Mit easyvdr habe ich das identische Fehlerbild


    Ich wäre um Hilfe dankbar. Mir ist bewusst, das dies eine sehr alte und spezielle Hardware ist, aber ich schätze die Möglichkeiten des Plugins mit dem VDR das Verhalten des TFT´s zu beeinflussen.


    Vielen Dank für die Hilfe im Vorraus!

    Wo kann man sich denn die Sourcen für das Plugin holen? Ist das in Gen2VDR identisch mit dem aus ICE-TFT an & aus per Software **NEU mit PLUGIN** oder gibt es da Unterschiede?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von rural

    Mit yaVDR kriege ich aber das Display nicht an hier erhalte ich "Speicherfehler" und laut logdate mit dem Komandozeilenprogramm "serialtft":


    "serialtft[1996]: segfault at 4006d0 ip 00007fc9880dd554 sp 00007ffdffed5248 error 7 in libc-2.19.so[7fc988055000+1bb000]"


    Mit kompilieren des Plugins erzeuge ich einen Absturz. Mit easyvdr habe ich das identische Fehlerbild

    Kannst du das etwas ausführen, wie du das Programm serialtft startest, welchen Pfad die serielle Schnittstelle für das Display hat usw. ?
    Was siehst du im Backtrace, wenn du serialtft mit gdb startest und es zum Crash kommt?


    Hat der User vdr die nötigen Rechte, um auf die Schnittstelle zuzugreifen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Entschuldigung für die späte Antwort. Ich hoffe ich habe alles richtig gemacht:


    Link zur Schnittstelle:
    lrwxrwxrwx 1 root root 7 Mai 5 11:52 ICE -> ttyUSB0


    Schnittstelle:
    crw-rw---- 1 root dialout 188, 0 Mai 5 11:52 ttyUSB0

    serialtft:
    -rw-rw-r-- 1 root root 209 Mai 5 12:02 Makefile
    -rw-rw-r-- 1 root root 715 Apr 30 15:18 readme.de
    -rwxr-xr-x 1 root root 11438 Mai 5 12:02 serialtft
    -rw-rw-r-- 1 root root 1842 Apr 30 15:18 serialtft.c


    gdb:
    (gdb) run serialtft on /dev/ICE
    Starting program: /root/serialtft/serialtft serialtft on /dev/ICE


    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff7a9d554 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
    (gdb)

    Ok, dann installierst du dir am besten noch die Debug-Symbole für die libc6 - die sind im Paket libc6-dbg.
    Und nach dem Crash kannst du dir in gdb mit "bt" bzw. "bt full" anzeigen lassen, wo genau das Programm gestolpert ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Vielen Dank für die Hilfe und die superschnelle Antwort!!!


    Das kriege ich jetzt:
    Starting program: /root/serialtft/serialtft on /dev/ICE


    Program received signal SIGSEGV, Segmentation fault.
    __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:41
    41 ../sysdeps/x86_64/multiarch/../strcpy.S: Datei oder Verzeichnis nicht gefunden.

    (gdb) bt
    #0 __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:41
    #1 0x000000000040087b in main (argc=3, argv=0x7fffffffe638) at serialtft.c:48

    (gdb) bt full
    #0 __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:41
    No locals.
    #1 0x000000000040087b in main (argc=3, argv=0x7fffffffe638) at serialtft.c:48
    state = 0
    port = 0x4006d0 <_start> "1\355I\211\321^H\211\342H\203\344\360PTI\307\300`\n@"


    Verstehe ich das richtig, das hier strcpy.S fehlt?

    Sicher dass dieses 'serialtft' in dieser Version jemals funktioniert hat?


    Code
    serialtft.c:27:	char *port;
(..)
serialtft.c:48:            strcpy(port,argv[2]);


    Zeile 48 versucht strcpy auszuführen ohne Speicher bereit zu stellen, port ist einfach ein nicht initialisierter Pointer.
    Könnte eher mit


    Code
    char port[256] = { 0 };


    funzen.

    Ich habe mit C noch wenig Erfahrung gesammelt, aber für mich sieht da so aus, als ob strcpy ein Problem hat, weil der Pointer *port auf nichts sinnvolles zeigt, wo man den String hinkopieren könnte.



    Wenn ich diese Änderungen vornehme, komme ich bis an die Stelle, wo er versucht auf das Gerät zuzugreifen:

    Dateien

    fix-pointer-operation.diff 509 Byte – 27 Downloads

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Der Patch hat funktioniert. Das Display geht an und aus. Vielen Dank für die Hilfe !!!!!


    Ich finde nur leider im Plugin selbst nicht eine ähnliche Stelle um diese anzupassen. Habt Ihr hier evtl. auch noch einen Tip für mich?


    Vielen Dank!!!

    Um mal darauf zurückzukommen:

    Zitat von rural

    Mit kompilieren des Plugins erzeuge ich einen Absturz.

    Passiert der Crash wirklich wenn du make aufrufst oder erst beim Laden bzw. Nutzen des Plugins?
    Ich kann am WE mal versuchen ein Paket für das Plugin zu schüren, aber da wäre es zuvor schön zu wissen, ob es prinzipiell funktioniert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Also wenn ich die Abhängigkeiten installiere, kann ich das Plugin zumindest ohne Fehlermeldungen bauen:

    Code
    apt-get install vdr-dev pkg-config
apt-get build-dep vdr


    Code
    make clean
make \ 
       CFLAGS="$(pkg-config vdr --variable=cflags)" \
       CXXFLAGS="$(pkg-config vdr --variable=cxxflags)" \
       VDRDIR="/usr/include/vdr" \
       LIBDIR="$(pkg-config vdr --variable=libdir)" \
       LOCALEDIR="$(pkg-config vdr --variable=locdir)" \
       all

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Vielen Dank für Dein Engamount bei meinen Exotenprobem!


    Oh, entschuldigung, ich glaube ich habe es falsch beschrieben.


    Bauen konnte ich das Plugin auch immer aus dem Source von gen2vdr und wird auch gestartet:


    Ich meine ich habe die VDR-Quelledateien mit apt-get source vdr und apt-get install vdr-dev aufgespielt.


    Dann in /usr/local/src/vdr-2.2.0/PLUGINS/src den Quellcode kopiert ins Verzeichnis icetft.


    Mit make plugins in /usr/local/src/vdr-2.2.0/ die lib erzeugt und diese nach /usr/lib/vdr/plugins enstepechend umbenannt kopiert:


    -rw-r--r-- 1 root root 228277 Mai 6 09:58 libvdr-icetft.so.2.2.0


    In etc/vdr/conf.avail eine Datei namens icetft.conf angelegt (-rw-r--r-- 1 root root 21 Mai 5 11:47 icetft.conf) mit dem Inhalt:


    [icetft]
    -d /dev/ICE


    und dann einen Link dazu in etc/vdr/conf.d


    lrwxrwxrwx 1 root root 25 Mai 5 11:55 50-icetft.conf -> ../conf.avail/icetft.conf


    Das Plugin ist dann auch im Menu vom VDR aufgeführt. Wenn ich dieses allerdings dann auswähle, dann hängt der VDR bzw. das Menü. Ich kann weder per Tastatur oder Lirc steuern. Ich sehe auch in der syslog keinen Eintrag.


    Es sollte auch eine OSD kommen mit "TFT wird angeschaltet" oder so. Das sehe ich auch nicht.

    Zitat von rural

    Das Plugin ist dann auch im Menu vom VDR aufgeführt. Wenn ich dieses allerdings dann auswähle, dann hängt der VDR bzw. das Menü. Ich kann weder per Tastatur oder Lirc steuern. Ich sehe auch in der syslog keinen Eintrag.


    Es sollte auch eine OSD kommen mit "TFT wird angeschaltet" oder so. Das sehe ich auch nicht.

    Tauchen im Syslog beim Start des VDR oder beim Öffnen des Menüs irgendwelche Meldungen von dem Plugin auf?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dann bring den VDR mal in den Zustand, in dem er hängt und häng dich mit gdb an den Prozess - dann kannst du nachsehen, was das Plugin zuletzt gemacht hat:

    Code
    gdb attach $(pidof vdr)
# dann in gdb
bt
bt full

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Das macht er:


    (gdb) bt
    #0 0x00007f586560cf3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
    #1 0x00007f586563e4a4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
    #2 0x00007f586111b52a in cIcetftSwitch::getTftState (this=0x1d49a40) at IcetftSwitch.c:194
    #3 0x00007f586111b1dd in cPluginIcetft::MainMenuAction (this=<optimized out>) at icetft.c:154
    #4 0x00000000004c2d0f in cMenuMain::ProcessKey(eKeys) ()
    #5 0x0000000000470337 in main ()


    (gdb) bt full
    #0 0x00007f586560cf3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
    No locals.
    #1 0x00007f586563e4a4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
    ts = {tv_sec = 0, tv_nsec = 2000000}
    #2 0x00007f586111b52a in cIcetftSwitch::getTftState (this=0x1d49a40) at IcetftSwitch.c:194
    No locals.
    #3 0x00007f586111b1dd in cPluginIcetft::MainMenuAction (this=<optimized out>) at icetft.c:154
    tftstate = <optimized out>
    #4 0x00000000004c2d0f in cMenuMain::ProcessKey(eKeys) ()
    No symbol table info available.
    #5 0x0000000000470337 in main ()
    No symbol table info available.
    (gdb)

    Scheint als würde er da in einer Endlosschleife in der IcetftSwitch.c hängen bleiben - beim öffnen des Menü setzt er die tftAction auf "toggle":


    Und solange tftAction nicht wieder auf error wechselt, dreht das Plugin da endlos seine Kreise:

    Code
    tState cIcetftSwitch::getTftState()
{
    while (tftAction!=error)
        usleep (TFT_SLEEP_TIME);
    return tftState;
}


    An die Mitleser, die mit C mehr Erfahrung haben:
    Wie ist das denn, wenn man eine Variable in C durch Threads manipuliert - muss die da nicht als volatile markiert werden oder darf das wirklich ein einfaches enum sein?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Wenn ich die Status-Variablen als volatile markiere (und dem Plugin zum Testen ein tty* Gerät unterschiebe, auf das es schreiben darf), bleibt er im Menü nicht mehr hängen:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden