Coredump mit plugin graphlcd

  • Hallo,


    wenn ich das graphlcd plugin mit vdr-2.4.0 laden möchte erhalte ich einen (core dumped)


    Code
    1. $ /usr/sbin/vdr -v /video -D0 -u vdr -p 6419 --plugin='dvbhddevice' --plugin='dvbsddevice' --plugin='softhddevice -g 1680x1050 -a hw:0,0 -d :1.0 -v vdpau' --plugin='graphlcd' --userdump
    2. [martin@fc29 ~]$ /usr/sbin/vdr -v /video -D0 -u vdr -p 6419 --plugin='dvbhddevice' --plugin='dvbsddevice' --plugin='softhddevice -g 1680x1050 -a hw:0,0 -d :1.0 -v vdpau' --plugin='graphlcd' --userdump
    3. /usr/include/c++/8/bits/basic_string.h:1039: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference = const char&; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]: Assertion '__pos <= size()' failed.
    4. Aborted (core dumped)


    Beim Core dump analysieren habe ich dann noch einen Backtrace erstellt.

    Kann da jemand was mit anfangen, liegt es am Compiler ?

    installiert sind die Pakete:

    gcc-Version 8.2.1

    vdr-2.4.0

    graphlcd-base-1.0.1

    vdr-graphlcd-1.0.1

    Gruß MartinKG

    Fedora29 x86_64 Gnome Desktop vdr 2.4.0 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von MartinKG ()

  • Hi,

    Deine aktiven Plugins machen keinen Sinn! Entweder Softhddevice mit Vdpau oder Full-featured SD oder HD.

    Wie ist denn deine graphlcd.conf?

    Welches graphlcd soll angesteuert werden?


    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easyvdr.de

  • Ehrlich gesagt verwende ich das Plugin gar nicht.

    Ich wollte eigentlich nur einem Benutzer der weiterhelfen, der sich in der vdr mailing list

    mit einem Problem zu graphlcd gemeldet hatte. Ich hatte ihm hierzu für Fedora rpm Pakete zur Verfügung gestellt.


    Hier seine Fehlermeldung aus der vdr mailing list:

    Gruß MartinKG

    Fedora29 x86_64 Gnome Desktop vdr 2.4.0 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von MartinKG ()

  • Hi,

    Und der Patch dafür aus dem Sammelthread ist drin.?


    Und graplcd-base auch gebaut + geladen?

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easyvdr.de

  • benötigt graphlcd-base-1.0.1 noch einen Patch ? und wo bekomme ich den ?


    Die folgenden Pakete wurden installiert:

    glcdgraphics-1.0.1-1.fc29.x86_64

    graphlcd-common-1.0.1-1.fc29.x86_64

    graphlcd-devel-1.0.1-1.fc29.x86_64

    graphlcd-tools-1.0.1-1.fc29.x86_64

    Gruß MartinKG

    Fedora29 x86_64 Gnome Desktop vdr 2.4.0 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von MartinKG ()

  • Eigentlich sollte alles ohne Patch gehen.


    Wäre interessant Infos zu bekommen wie man das ggf. nachstellen kann. Ich könnte dann versuchen das am Wochenende nachzustellen.


    Allerdings kann ich wenig helfen wenn der Fehler nur mit dem VDR-Plugin auftritt. Das nutze ich schon lange nicht mehr und kann auch nicht so ohne weiteres eine Testumgebung dafür bauen.


    Und falls es für das VDR-Plugin doch einen Patch geben sollte, dann immer her damit. Ich könnte das am Wochenende direkt ins GIT commiten.

  • #4 trim (s="") at strfct.c:60


    Kann da jemand was mit anfangen, liegt es am Compiler ?

    installiert sind die Pakete:


    gcc-Version 8.2.1

    Das Minimalbeispiel wäre dann die trim-Funktion auf einen leeren String los zu lassen - magst du das mal ausprobieren?

    Und dann so bauen und ausführen:

    Code
    1. g++ test.cpp
    2. ./a.out

    Bei mir knallt das mit Fedora 29, aber nicht mit gcc 8.2.0 unter Arch Linux und früheren gcc-Versionen unter Ubuntu.


    Kann mir jemand erklären, warum das jemals funktioniert hat, dass ein unsigned Datentyp wie string::size_type (laut http://www.cplusplus.com/reference/string/string/size/) einen Wert kleiner Null bekommen kann (muss er ja, damit die while-Schleife in Zeile 18 rechtzeitig beendet wird? Gibt es da mit den bisherigen gcc-Versionen einen Cast zu einem signed Typ oder warum hat das bislang funktioniert?


    Vielleicht sollte man da eine ordentliche trim-Methode wie aus https://stackoverflow.com/a/217605 nehmen, wenn man die Vorteile von C++11 oder später mitnehmen kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich würde die zweite Schleife anders programmieren:

    Code
    1. end = s.length;
    2. while (end > start)
    3. {
    4. end--;
    5. if (!isspace(s[end]))
    6. break;
    7. }
    8. if (end == start)
    9. return "";
    10. return s.substr(start, end - start + 1);

    Hab's jetzt nur im Kopf programmiert, bitte testen...

    Es macht keinen Sinn, end bis runter zum Anfang laufen zu lassen. Und so hat man auch kein Problem, dass end kleiner Null werden kann. Mab muss natürlich den Spezialfall eines reinen Whitespace-Strings beachten.


    Lars.

  • Die Lösung von stackoverflow verschiebt für mein Gefühl unnötig Bytes. Erst rtrim, dann ltrim macht es besser, wie die alte Lösung.


    Lars

  • boost hat auch eine trim-Funktion, damit spart man sich das Basteln: https://www.boost.org/doc/libs…o/usage.html#id-1.3.3.5.5

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Und dann so bauen und ausführen:

    Code
    1. g++ test.cpp
    2. ./a.out

    Bei mir knallt das mit Fedora 29, aber nicht mit gcc 8.2.0 unter Arch Linux und früheren gcc-Versionen unter Ubuntu.

    das macht er bei mir mit ( g++ (GCC) 8.2.1 20181011 (Red Hat 8.2.1-4 )

    Code
    1. g++ test.cpp -o test
    2. $ ./test
    3. /builddir/build/BUILD/gcc-8.2.1-20181011/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.h:1039: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference = const char&; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]: Assertion '__pos <= size()' failed.
    4. Aborted (Speicherabzug geschrieben)

    Gruß MartinKG

    Fedora29 x86_64 Gnome Desktop vdr 2.4.0 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

  • Ich würde die zweite Schleife anders programmieren:

    Code
    1. end = s.length;
    2. while (end > start)
    3. {
    4. end--;
    5. if (!isspace(s[end]))
    6. break;
    7. }
    8. if (end == start)
    9. return "";
    10. return s.substr(start, end - start + 1);

    Hab's jetzt nur im Kopf programmiert, bitte testen...

    Es macht keinen Sinn, end bis runter zum Anfang laufen zu lassen. Und so hat man auch kein Problem, dass end kleiner Null werden kann. Mab muss natürlich den Spezialfall eines reinen Whitespace-Strings beachten.


    Lars.


    Mit deinem Code

    gibt er dann folgendes aus:


    $ ./test2

    trimmed string: ''


    Gruß Marco


    HW: TeVii S471 S/S2, TT6400-S2
    SW: Fedora 29, kernel-4.19.2-300.fc29.x86_64, vdr-2.4.0-4.fc29.x86_64

  • Das scheint für ASCII (und UTF-8) generell gut zu funktionieren.


    Abgesehen von den Einträgen aus der channels.alias scheint die Funktion auch noch auf Radiotext (das kann neben UTF-8 auch UCS-2 (bzw. ein Teilbereich von UTF-16) sein) - weiß jemand, ob und wie die Daten im VDR dekodiert werden?) und Menü-Einträge angewendet zu werden.

    Kann mir jemand erklären, warum das jemals funktioniert hat, dass ein unsigned Datentyp wie string::size_type (laut http://www.cplusplus.com/reference/string/string/size/) einen Wert kleiner Null bekommen kann (muss er ja, damit die while-Schleife in Zeile 18 rechtzeitig beendet wird? Gibt es da mit den bisherigen gcc-Versionen einen Cast zu einem signed Typ oder warum hat das bislang funktioniert?

    Verstehe ich das richtig, dass die while-Schleife selbst mit dem Vergleich von einem unsigned int mit einem int an sich endlos laufen würde, aber der Zugriff auf Positionen über das Ende des Strings hinaus undefiniertes Verhalten erzeugt und die while-Schleife dann stoppt, wenn man dabei ein Byte erwischt, das als Whitespace zählt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Interessanter Fund.

    Dieses "trim" ist in der Form mindestens zweimal in graphlcd-base und einmal im VDR-Plugin.

    Und ich bin aktuell wirklich am Überlegen ob es Sinn macht die eigene Implementierung überhaupt drin zu lassen oder doch besser Boost zu nutzen.

    Eine neue Abhängigkeit entsteht scheinbar dabei nicht. Boost muss wohl nur beim Kompilieren da sein.

  • Grundsätzlich sollte man Räder nicht neu erfinden, wenn man vorhandene nutzen kann.


    Letztendlich muss man seine Funktion eben nur mit passenden Daten testen. Die ursprüngliche Funktion wurde nie mit reinen Whitespace-Strings getestet. Dann muss man noch einen leeren String testen, einen ohne Whitespace vorne und hinten und jeweils etwas Whitespace nur vorne oder hinten und Whitespace vorne und hinten. Mehr Fälle sollte es nicht geben.


    Lars

  • Die ursprüngliche Funktion ging bei einigen Compilern ja auch.

    Die Lösung die ich jetzt drin habe nutzt so viel stdlib wie möglich. Keine eigenen Schleifen mehr.

    Den Fall "alles sind Whitespaces" fange ich extra ab obwohl auch das bei mir wieder ohne extra Behandlung ging. Würde in dem Fall aber wieder negativ, weshalb ich auf Nummer sicher gegangen bin.


    Mich stört nach wie vor das es die Funktion in graphlcd-base doppelt gibt. Außerdem sind mir weitere Funktionen aufgefallen, die es in der stdlib bereits gibt und die deshalb nicht neu gebaut werden müssen. Ich gehe da also nochmal dran und räume noch etwas auf.

  • In der letzten Zeile müsste right - left + 1 als Länge für substr auch reichen.


    Aber auch die std::string Funktionen verstehen nichts von Encodings, oder? Die behandeln das doch auch nur als byte-Array, wenn ich mich richtig erinnere. Das kann ein Problem sein, wenn von einem Multibyte-Zeichen das erste bzw. letzte Byte wie ein Whitespace aussieht und deswegen weggeschnitten wird. Dann hat man ein kaputtes Encoding.


    Lars

  • Nein, reicht nicht. Die Zahlen sind beide "hochlaufend".

    "left" gibt also die Anzahl von Leerzeichen "von links" an und "right" das gleiche "von rechts".

    Sind also keine Positionen im String.


    Und das mit dem Encoding hat jede Funktion. Keine Ahnung was da die "saubere" Lösung wäre. Wenn es sie überhaupt gibt. "isspace" nimmt nämlich auch nur ein Byte.