Coredump mit plugin graphlcd

MartinKG · Nov 8th 2018

Hallo,

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

Code

$ /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
[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
/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.
Aborted (core dumped)

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

Code

[martin@fc29 ~]$ coredumpctl gdb $PID
PID: 16145 (vdr)
UID: 1000 (martin)
GID: 1000 (martin)
Signal: 6 (ABRT)
Timestamp: Thu 2018-11-08 17:16:01 CET (2min 1s ago)
Command Line: /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
Executable: /usr/sbin/vdr
Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
Unit: user@1000.service
User Unit: gnome-terminal-server.service
Slice: user-1000.slice
Owner UID: 1000 (martin)
Boot ID: 294b8eabf4cb40b2972cf2e46ac1cd52
Machine ID: 5d9416d31cdf487a89d1f3af5444ef02
Hostname: fc29
Storage: /var/lib/systemd/coredump/core.vdr.1000.294b8eabf4cb40b2972cf2e46ac1cd52.16145.1541693761000000.lz4
Message: Process 16145 (vdr) of user 1000 dumped core.
Stack trace of thread 16145:
#0 0x00007f4133e8d53f raise (libc.so.6)
#1 0x00007f4133e77895 abort (libc.so.6)
#2 0x00007f413318762c _ZSt20__replacement_assertPKciS0_S0_ (libvdr-graphlcd.so.2.4.0)
#3 0x00007f4133171e31 _ZN17cChannelAliasList4LoadERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (libvdr-graphlcd.so.2.4.0)
#4 0x00007f413317ec0f _ZN19cGraphLCDSkinConfigC2EPK16cGraphLCDDisplayRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESA_SA_P14cGraphLCDState (libvdr-graphlcd.so.2.4.0)
#5 0x00007f4133176e44 _ZN16cGraphLCDDisplay10InitialiseEPN4GLCD7cDriverERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESA_SA_ (libvdr-graphlcd.so.2.4.0)
#6 0x00007f4133178e3b _ZN15cPluginGraphLCD14ConnectDisplayEjj (libvdr-graphlcd.so.2.4.0)
#7 0x00007f4133179c6b _ZN15cPluginGraphLCD10InitializeEv (libvdr-graphlcd.so.2.4.0)
#8 0x00005603ca215f21 _ZN14cPluginManager17InitializePluginsEv (vdr)
#9 0x00005603ca1953dd main (vdr)
#10 0x00007f4133e79413 __libc_start_main (libc.so.6)
#11 0x00005603ca1989de _start (vdr)
Stack trace of thread 16149:
#0 0x00007f4133f47371 __poll (libc.so.6)
#1 0x00005603ca261201 _ZN7cPoller4PollEi (vdr)
#2 0x00005603ca1bbf64 _ZNK9cDvbTuner15ClearEventQueueEv (vdr)
#3 0x00005603ca1bbfc8 _ZNK9cDvbTuner17GetFrontendStatusER9fe_status (vdr)
#4 0x00005603ca1bf0fc _ZN9cDvbTuner6ActionEv (vdr)
#5 0x00005603ca255335 _ZN7cThread11StartThreadEPS_ (vdr)
#6 0x00007f413451f58e start_thread (libpthread.so.0)
#7 0x00007f4133f52593 __clone (libc.so.6)
Stack trace of thread 16146:
#0 0x00007f4133f42ed4 __read (libc.so.6)
#1 0x00007f4133ed3c48 _IO_file_underflow@@GLIBC_2.2.5 (libc.so.6)
#2 0x00007f4133ec80a8 __getdelim (libc.so.6)
#3 0x00005603ca260fdc _ZN9cReadLine4ReadEP8_IO_FILE (vdr)
#4 0x00005603ca218e1b _ZN14cRecordingInfo4ReadEP8_IO_FILE (vdr)
#5 0x00005603ca21d5b0 _ZN10cRecordingC1EPKc (vdr)
#6 0x00005603ca221a60 _ZN28cVideoDirectoryScannerThread12ScanVideoDirEPKcii (vdr)
#7 0x00005603ca221ad8 _ZN28cVideoDirectoryScannerThread12ScanVideoDirEPKcii (vdr)
#8 0x00005603ca221c52 _ZN28cVideoDirectoryScannerThread6ActionEv (vdr)
#9 0x00005603ca255335 _ZN7cThread11StartThreadEPS_ (vdr)
#10 0x00007f413451f58e start_thread (libpthread.so.0)
#11 0x00007f4133f52593 __clone (libc.so.6)
Stack trace of thread 16147:
#0 0x00007f4133f4d09b __mprotect (libc.so.6)
#1 0x00007f4133ed969b sysmalloc (libc.so.6)
#2 0x00007f4133eda816 _int_malloc (libc.so.6)
#3 0x00007f4133edbbca malloc (libc.so.6)
#4 0x00007f4133eb8017 _IO_vfscanf (libc.so.6)
#5 0x00007f4133ec96e1 vsscanf (libc.so.6)
#6 0x00007f4133ec3c98 _IO_sscanf (libc.so.6)
#7 0x00005603ca1d270c _ZN10tComponent10FromStringEPKc (vdr)
#8 0x00005603ca1d3631 _ZN6cEvent5ParseEPc (vdr)
#9 0x00005603ca1d52d1 _ZN6cEvent4ReadEP8_IO_FILEP9cScheduleRi (vdr)
#10 0x00005603ca1d6b93 _ZN9cSchedule4ReadEP8_IO_FILEP10cSchedules (vdr)
#11 0x00005603ca1d6c40 _ZN10cSchedules4ReadEP8_IO_FILE (vdr)
#12 0x00005603ca255335 _ZN7cThread11StartThreadEPS_ (vdr)
#13 0x00007f413451f58e start_thread (libpthread.so.0)
#14 0x00007f4133f52593 __clone (libc.so.6)
Stack trace of thread 16150:
#0 0x00007f4133f47371 __poll (libc.so.6)
#1 0x00005603ca22bcca _ZN15cSectionHandler6ActionEv (vdr)
#2 0x00005603ca255335 _ZN7cThread11StartThreadEPS_ (vdr)
#3 0x00007f413451f58e start_thread (libpthread.so.0)
#4 0x00007f4133f52593 __clone (libc.so.6)
GNU gdb (GDB) Fedora 8.2-3.fc29
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/vdr...(no debugging symbols found)...done.
[New LWP 16145]
[New LWP 16149]
[New LWP 16146]
[New LWP 16147]
[New LWP 16150]
warning: Loadable section ".note.gnu.property" outside of ELF segments
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
Core was generated by `/usr/sbin/vdr -v /video -D0 -u vdr -p 6419 --plugin=dvbhddevice --plugin=dvbsdd'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4133e8d53f in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f4133ab8d80 (LWP 16145))]
Missing separate debuginfos, use: dnf debuginfo-install vdr-2.4.0-4.fc29.x86_64
(gdb) bt
#0 0x00007f4133e8d53f in raise () from /lib64/libc.so.6
#1 0x00007f4133e77895 in abort () from /lib64/libc.so.6
#2 0x00007f413318762c in std::__replacement_assert (__condition=0x7f413319013c "__pos <= size()", __function=<synthetic pointer>, __line=1039, __file=0x7f41331900f0 "/usr/include/c++/8/bits/basic_string.h") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2391
#3 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator[] (__pos=<optimized out>, this=<optimized out>) at /usr/include/c++/8/bits/basic_string.h:1039
#4 trim (s="") at strfct.c:60
#5 0x00007f4133171e31 in cChannelAliasList::Load (this=this@entry=0x5603cb39ba58, CfgPath="/usr/share/vdr/plugins/graphlcd") at /usr/include/c++/8/bits/basic_string.h:252
#6 0x00007f413317ec0f in cGraphLCDSkinConfig::cGraphLCDSkinConfig (this=0x5603cb39b9e0, Display=<optimized out>, CfgPath="/usr/share/vdr/plugins/graphlcd", SkinsPath=..., SkinName="default", State=0x5603cb38a260) at skinconfig.c:333
#7 0x00007f4133176e44 in cGraphLCDDisplay::Initialise (this=this@entry=0x5603caf21940, Lcd=<optimized out>, CfgPath="/usr/share/vdr/plugins/graphlcd", SkinsPath="", SkinName="default") at display.c:92
#8 0x00007f4133178e3b in cPluginGraphLCD::ConnectDisplay (this=0x5603caf1f580, index=0, displayNumber=<optimized out>) at /usr/include/c++/8/bits/basic_string.h:252
#9 0x00007f4133179c6b in cPluginGraphLCD::Initialize (this=0x5603caf1f580) at plugin.c:261
#10 0x00005603ca215f21 in cPluginManager::InitializePlugins() ()
#11 0x00005603ca1953dd in main ()
(gdb)

Display More

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

SurfaceCleanerZ · Nov 8th 2018

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

MartinKG · Nov 8th 2018

SurfaceCleanerZ wrote:

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

Display More

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:

Code

/usr/sbin/vdr --grab=/tmp --no-kbd --shutdown=vdr-shutdown.sh
--plugin=dvbhddevice --plugin=graphlcd -l 3.7
/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.

Display More

SurfaceCleanerZ · Nov 8th 2018

Hi,

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

Und graplcd-base auch gebaut + geladen?

Mfg Stefan

MartinKG · Nov 8th 2018

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

M-Reimer · Nov 8th 2018

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.

seahawk1986 · Nov 8th 2018

MartinKG wrote:

#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?

C: test.cpp

#include <string>
#include <iostream>
using namespace std;
string trim(const string & s)
{
string::size_type start, end;
start = 0;
while (start < s.length())
{
if (!isspace(s[start]))
break;
start++;
}
end = s.length() - 1;
while (end >= 0)
{
if (!isspace(s[end]))
break;
end--;
}
return s.substr(start, end - start + 1);
}
int main() {
string test = "";
string out = trim(test);
cout << "trimmed string: '" << out << "'" << endl;
}

Display More

Und dann so bauen und ausführen:

Code

g++ test.cpp
./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.

mini73 · Nov 8th 2018

Ich würde die zweite Schleife anders programmieren:

Code

end = s.length;
while (end > start)
{
end--;
if (!isspace(s[end]))
break;
}
if (end == start)
return "";
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.

mini73 · Nov 8th 2018

Müsste man aber auch mal für nicht Single-Byte-Encodings testen.

Lars

mini73 · Nov 8th 2018

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

seahawk1986 · Nov 8th 2018

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

MartinKG · Nov 9th 2018

seahawk1986 wrote:

Und dann so bauen und ausführen:

Code

g++ test.cpp

./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

g++ test.cpp -o test
$ ./test
/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.
Aborted (Speicherabzug geschrieben)

marco · Nov 9th 2018

mini73 wrote:

Ich würde die zweite Schleife anders programmieren:

Code

end = s.length;

while (end > start)

{

end--;

if (!isspace(s[end]))

break;

}

if (end == start)

return "";

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

C

#include <string>
#include <iostream>
using namespace std;
string trim(const string & s)
{
string::size_type start, end;
start = 0;
while (start < s.length())
{
if (!isspace(s[start]))
break;
start++;
}
end = s.length();
while (end > start)
{
end--;
if (!isspace(s[end]))
break;
}
if (end == start)
return "";
return s.substr(start, end - start + 1);
}
int main() {
string test = "";
string out = trim(test);
cout << "trimmed string: '" << out << "'" << endl;
}

Display More

gibt er dann folgendes aus:

$ ./test2

trimmed string: ''

seahawk1986 · Nov 9th 2018

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.

seahawk1986 wrote:

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?

M-Reimer · Nov 9th 2018

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.

M-Reimer · Nov 9th 2018

Ich habe mich jetzt mal selber an einer "trim"-Funktion versucht.

Bitte mal den GIT-Stand testen ob es damit geht.

mini73 · Nov 9th 2018

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

M-Reimer · Nov 9th 2018

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.

mini73 · Nov 9th 2018

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

M-Reimer · Nov 9th 2018

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.

Coredump mit plugin graphlcd

Share

Tags