[yaVDR64-0.5.0-alpha1]vdr wird sporadisch beim starten gekillt

BooStar · 21. Juni 2012

Hallo zusammen,
da bin ich schon wieder
während der letzten reboot-orgie habe ich mal die startzeiten gemessen,
dabei ist mir aufgefallen, das der vdr manchmal innerhalb von 30 sek. startet (gemessen ab grub)
und manchmal dauert es doppelt bis dreimal solange..
kennt das problem vllt irgendwer?

ein log liegt hier, ich habe die stelle mal markiert..

veni32 · 21. Juni 2012

War das auch so vor dem bösen plugin instalation!?

Das gefühl hab ich gestern auch gehabt das bootvorgang unterschiedlich lange dauet nach SC instalation.

Ewentuell hat es mit Distri nichts zutun,sonder mit bösewicht.

MfG

BooStar · 21. Juni 2012

hallo

Zitat

War das auch so vor dem bösen plugin instalation!?

ich denke schon, genau weiss ich es nicht.. werde es gleich nochmal testen...

BooStar · 21. Juni 2012

hallo nochmal...

Code

War das auch so vor dem bösen plugin instalation!?

es ist aufjedenfall auch ohne den boesewicht so ...
das hier macht mir halt ein wenig sorgen, ich glaube das sollte nicht so sein:

Code

Jun 21 23:49:53 yavdr vdr: video/vdpau: 10bit RGBA format with 8192x8192 supported
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.epg
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.osd
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.plugin
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.recording
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.remote
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.setup
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.shutdown
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.skin
Jun 21 23:49:53 yavdr vdr: [1683] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.timer
Jun 21 23:49:54 yavdr vdr: [1653] ERROR: text2skin: Couldn't load /var/lib/vdr/channellogos/logobg.png: vdr: unable to open file `/var/lib/vdr/channellogos/l$
Jun 21 23:49:54 yavdr kernel: [   39.726176] Text2Skin: chan[1653]: segfault at 375b000 ip 00007f4a611d2664 sp 00007f4a237f4bb8 error 4 in libc-2.15.so[7f4a6$
Jun 21 23:49:54 yavdr kernel: [   39.768446] init: vdr main process (1163) killed by SEGV signal
Jun 21 23:50:19 yavdr dbus[928]: [system] Failed to activate service 'de.tvdr.vdr': timed out
Jun 21 23:50:19 yavdr vdr-crash: vdr exit with signal SEGV . Restarting
Jun 21 23:50:19 yavdr kernel: [   64.872373] init: vdr-exit-other main process (2100) terminated with status 1
Jun 21 23:50:19 yavdr vdr: [2109] VDR version 1.7.27 started
Jun 21 23:50:19 yavdr vdr: [2109] switched to user 'vdr'
Jun 21 23:50:19 yavdr vdr: [2109] codeset is 'UTF-8' - known
Jun 21 23:50:19 yavdr vdr: [2109] found 28 locales in /usr/share/locale
Jun 21 23:50:19 yavdr vdr: [2109] loading plugin: /usr/lib/vdr/plugins/libvdr-menuorg.so.1.7.27

Alles anzeigen

mini73 · 22. Juni 2012

Moin!

Ja, da scheint irgendwas in text2skin nicht zu stimmen, jedenfalls stürzt es ab.
vdr-Debugversion installieren und Plugin mit Debugsymbolen übersetzen, backtrace erstellen, Stelle im Plugin identifizieren und dem Autor einen Patch schicken bzw. ihn/sie darauf aufmerksam machen.

Aber warum beendet sich der vdr? Der Absturz kommt ja erst beim Stoppen des vdr.
Was steht weiter vorne im Log?

Lars.

BooStar · 22. Juni 2012

Hi mini73,

Zitat

vdr-Debugversion installieren und Plugin mit Debugsymbolen übersetzen, backtrace erstellen, Stelle im Plugin identifizieren und dem Autor einen Patch schicken bzw. ihn/sie darauf aufmerksam machen.

Jaa.. geeennaauu Ich habe zwar verstanden was du gesagt hast, aber umsetzen kann ich das so erstmal nicht..werde mich da aber mal einlesen und gucken was ich da rauszeihen kann
Das werde ich aber vor nächster Woche nicht schaffen, dieses WE ist leider vdr freie Zeit ...

Zitat

Aber warum beendet sich der vdr? Der Absturz kommt ja erst beim Stoppen des vdr.
Was steht weiter vorne im Log?

da ist im ersten post eins angeängt..

mini73 · 22. Juni 2012

Moin!

Zitat von BooStar

Jaa.. geeennaauu Ich habe zwar verstanden was du gesagt hast, aber umsetzen kann ich das so erstmal nicht..werde mich da aber mal einlesen und gucken was ich da rauszeihen kann
Das werde ich aber vor nächster Woche nicht schaffen, dieses WE ist leider vdr freie Zeit ...

Ich müsste auch erst nachsehen, wie ich das wohl machen müsste...

Zitat von BooStar

da ist im ersten post eins angeängt..

Das sieht aber vor dem Absturz etwas anders aus. Die Meldungen von dbus2vdr "deleting dispatcher" kommen erst, wenn der vdr herunterfährt/gestoppt wird.
Im ersten Log kommt der Absturz irgendwo mitten drin.

Hat also nicht unbedingt was mit dem Startvorgang zu tun, sondern dass der vdr (oder ein Plugin) etwas auf dem OSD anzeigen will und dann Text2Skin einen Absturz verursacht.
Kann also theoretisch auch mitten im Betrieb passieren. Ich meine, hier im Forum auch immer mal wieder von Problemen im Zusammenhang mit Text2Skin zu lesen.

Gegentest/Workaround: natives Skin benutzen und Text2Skin disablen. Dann müssten die Startzeiten eigentlich wieder stabil sein.

Lars.

hotzenplotz5 · 22. Juni 2012

http://www.yavdr.org/documentation/0.5/de/ch02s08.html

BOP · 22. Juni 2012

Du hast nicht zufällig den PearlHD Skin aktiv?

[yaVDR 0.5-alpha1] vdr Neustart bei Spulen oder anspringen einer Sprungmarke

mini73 · 22. Juni 2012

Moin!

Zitat von hotzenplotz5

http://www.yavdr.org/documentation/0.5/de/ch02s08.html

Da sollte noch mal ein Wissender dokumentieren, wie man ein Plugin mit Debug-Symbolen übersetzt...

Lars.

seahawk1986 · 22. Juni 2012

Ja, am besten einer mit sokratisch geprägtem Forums-Nickname, der frei übersetzt darauf hinausläuft: οἶδα οὐκ εἰδώς

Keine_Ahnung · 22. Juni 2012

Irgendwie fühle ich mich angesprochen

Ich hätte ja jetzt gesagt [yavdr0.4] Seit Update funktioniert der VDR nicht mehr mit graphtft-fe aber irgendwie geht meine Variante mit override_dh_Strip wohl doch nicht bei den e-Tobi Paketen.

Setzt euch doch mal zusammen (ich vermute e-Toby müsste da aktiv werden?) und bietet Debugpakete zusätzlich an. Das geht super und kostet nix extra, die kann man einfach dazu installieren und hat dann die Debugsymbole.

cu

BooStar · 25. Juni 2012

Hallo zusammen..
ich grade mal wieder ein update gemacht..
das verhalten hat sich nicht geändert...
hier ist erstmal ein vollständiges syslog. jetzt werde mich mir mal den bt ansehen
das ist irgendwie nicht so einfach

syslog

gruß
boostar

BooStar · 26. Juni 2012

Hallo zusammen,
wie schon gesagt habe ich es geschafft dem vdr einen core dump zu entlocken.
dies ist eine ca. 500MB große datei mit der ich so erstmal nichts anfangen kann.
Kann mir jemand einen Tip geben wie ich damit mit jetzt weiter umgehe?
Ich habe:
- vdr-Debugversion installieren: OK, core.1536 in /var/log/vdr vorhanden
- und Plugin mit Debugsymbolen übersetzen: das habe ich nicht gemacht, also ist der core dump wohl nutzlos, oder?
- backtrace erstellen: keine Ahnung wie das geht
- Stelle im Plugin identifizieren: auch das ist schwierig für mich
- und dem Autor einen Patch schicken: das bekomme ich niemals hin
- bzw. ihn/sie darauf aufmerksam machen: das könnte ich schaffen

vllt hat ja noch jemand ein paar nützliche Tips für mich..

gruß
Boostar

steffen_b · 26. Juni 2012

/etc/default/vdr anpassen und dort vdr-dbg als DAEMON eintragen. Siehe Handbuch. Es würde mich wundern wenn das automatische erstellen des Backtrace nicht mehr gehen sollte.

BooStar · 26. Juni 2012

hallo,
also das:

Code

echo "DAEMON=/usr/bin/vdr-dbg" >> /etc/default/vdr

das habe ich gemacht.. nach dem ich dann einen erneuten absturz hatte, war in /var/log/vdr auch eine core.1536 vorhanden.
Ist das etwa ein backtrace?

steffen_b · 26. Juni 2012

das ist der core-dump - Ist gdb bei dir installiert ? Dann könntest du diesen dazu benutzen ein Batcktrace vom core dump zu ziehen (Coredump = Speicherabbild des VDR Prozesses zum Zeitpunkt des Crashes)

BooStar · 26. Juni 2012

Hi steffen,

Zitat

Ist gdb bei dir installiert ?

Ja, gdb ist installiert..

Zitat

Dann könntest du diesen dazu benutzen ein Batcktrace vom core dump zu ziehen

Da muss ich erstmal herausfinden wie das funktioniert
Die Frage ist, ob das überhaupt was bringt, da text2skin ja nicht mit debug-symbolen übersetzt ist..wobei das sicherlich das kleinere Problem ist, wenn ich erstmal folgendes verstanden habe:

Zitat

- backtrace erstellen: keine Ahnung wie das geht
- Stelle im Plugin identifizieren: auch das ist schwierig für mich

gruß
BooStar

BooStar · 26. Juni 2012

Zitat

Da muss ich erstmal herausfinden wie das funktioniert

Das scheint mit

Code

gdb Programm -c core.PID

zu gehen.. Programm ist dann wahrscheinlich vdr.
und dann noch ein "bt" in gdb... werds mir später nochmal anschauen..

gruß
Boo

BooStar · 26. Juni 2012

Soo ich hab grad mal ein bischen gespielt..
das kommt dabei raus, vllt kann jemand was damit anfangen(ich nämlich nicht):

Code

root@yavdr:/var/log/vdr# gdb vdr-dbg core.1497
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 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-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/vdr-dbg...done.
[New LWP 1728]
[New LWP 1729]
[...]
[New LWP 1731]
[New LWP 1623]


warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vd'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f1482d3d6b3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f1482d3d6b3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f1483618842 in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007f1483618f5c in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007f1474af2b63 in cText2SkinRender::GetTokenData(txToken const&) () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#4  0x00007f1474aed069 in cText2SkinDisplayChannel::GetTokenData(txToken const&) () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#5  0x00007f1474af6f0b in cText2SkinRender::GetToken(txToken const&) () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#6  0x00007f1474b0f861 in cxString::Evaluate() const () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#7  0x00007f1474b15869 in cxFunction::Evaluate() const () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#8  0x00007f1474b15145 in cxFunction::Evaluate() const () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#9  0x00007f1474af56c0 in cText2SkinRender::DrawObject(cxObject*, txPoint const&, txSize const&, txSize const&, int, bool) ()
   from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#10 0x00007f1474af6cde in cText2SkinRender::Update() () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#11 0x00007f1474af6df8 in cText2SkinRender::Action() () from /usr/lib/vdr/plugins/libvdr-text2skin.so.1.7.27
#12 0x00000000004e04f8 in cThread::StartThread (Thread=0x35853a0) at thread.c:257
#13 0x00007f1484579e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007f1482d9e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x0000000000000000 in ?? ()
(gdb)

Alles anzeigen

[yaVDR64-0.5.0-alpha1]vdr wird sporadisch beim starten gekillt

Jetzt mitmachen!

Teilen