Segfault mit VDR 1.7.21

Zabrimus · 9. Oktober 2011

Hallo,

mein VDR-Server (1.7.21, e-Tobi Standard) lief eine Zeitlang problemlos durch. Nur startet dieser seit neustem immer wieder durch.
Zuerst hatte ich verschiedene Plugins im Verdacht, aber selbst nachdem ich diese alle deaktiviert habe, springt mich immer ein Segfault an.

Aktueller Aufruf von VDR (nach Deaktivierung aller Plugins):
Starting program: /usr/bin/vdr-dbg -v /share/nfs/video -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -E /var/cache/vdr/epg.data -w 0 --userdump --lirc

Code

Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xb2df8b70 (LWP 15230)]
 cListObject::Unlink (this=0xae9dd940) at tools.c:1795
 1795	tools.c: Datei oder Verzeichnis nicht gefunden.
     	in tools.c
 Current language:  auto
 The current source language is "auto; currently c++".
 (gdb) bt
 #0  cListObject::Unlink (this=0xae9dd940) at tools.c:1795
 #1  cListBase::Sort (this=0xae9dd940) at tools.c:1938
 #2  0x080c3a55 in cSchedule::Sort (this=0xae9dd920) at epg.c:980
 #3  0x080be439 in cEIT (this=0xb2df7240, Schedules=0x818fa40,  Source=1124073472, Tid=80 'P', Data=0xb2df7338 "P\362%Z@\331\300",  <incomplete sequence \370>, 
 	OnlyRunningStatus=false) at eit.c:310
 #4  0x080bf97c in cEitFilter::Process (this=0xb66440c8, Pid=18, Tid=80  'P', Data=0xb2df7338 "P\362%Z@\331\300", <incomplete sequence  \370>, Length=552) at eit.c:382
 #5  0x0810c763 in cSectionHandler::Action (this=0xb6644250) at sections.c:212
 #6  0x08128ab0 in cThread::StartThread (Thread=0xb6644250) at thread.c:257
 #7  0x00153955 in start_thread () from /lib/i686/cmov/libpthread.so.0
 #8  0x00437e7e in clone () from /lib/i686/cmov/libc.so.6

Alles anzeigen

Als Alternative erhalte ich auch folgenden BT:

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb11f4b70 (LWP 14546)]
cHashBase::Get (this=0x8baa134, Id=1318294800) at tools.c:1992
1992	tools.c: Datei oder Verzeichnis nicht gefunden.
    	in tools.c
Current language:  auto
The current source language is "auto; currently c++".
(gdb) bt
#0  cHashBase::Get (this=0x8baa134, Id=1318294800) at tools.c:1992
#1  0x080be6db in cEIT (this=0xb11f3240, Schedules=0x818fa40, Source=1124073472, Tid=80 'P', Data=0xb11f3338 "P\360qZ?׀", <incomplete sequence \370>, OnlyRunningStatus=false)
	at eit.c:68
#2  0x080bf97c in cEitFilter::Process (this=0xb6c33b88, Pid=18, Tid=80 'P', Data=0xb11f3338 "P\360qZ?׀", <incomplete sequence \370>, Length=116) at eit.c:382
#3  0x0810c763 in cSectionHandler::Action (this=0xb6c33d10) at sections.c:212
#4  0x08128ab0 in cThread::StartThread (Thread=0xb6c33d10) at thread.c:257
#5  0x00153955 in start_thread () from /lib/i686/cmov/libpthread.so.0
#6  0x00437e7e in clone () from /lib/i686/cmov/libc.so.6

Alles anzeigen

Das ganze passiert immer ein paar Minuten nach dem Start von VDR und ich weiß nicht mehr weiter

VG
Zabrimus

FireFly · 9. Oktober 2011

Lösche mal Deine epg.data bzw. nenne sie um während VDR gestoppt ist.

Zabrimus · 9. Oktober 2011

Die EPG-Data hatte ich schon einmal gelöscht. Der Erfolg dieser Aktion war recht unscheinbar: Es hat nichts gebracht. VDR stürzte immer noch ab.

Aber ich bin einen Schritt weiter. Mir ist aufgefallen, daß fast immer derselbe Kanal im Logfile zuletzt auftauchte, bei dem eine PID/Name-Änderung erfolgte. Bei mir war es Teleklub (DVB-C, Unitymedia)..

Nachdem ich diesen Kanal, alle ausländischen Kanäle und auch die Radiosender aus der channels.conf gelöscht habe (Paranoia pur) und in der setup.conf den Parameter UpdateChannels auf 0 setzte, läuft VDR nun schon seit phänomenalen 30 Minuten ohne Fehler.
Aktuell würde ich dies als Erfolg bezeichnen.

UpdateChannels auf den Default 5 brachte nur kurzfristig Erleichterung, einer der problematischen Kanäle wurde wieder gefunden und VDR beendete sich kurz danach wieder.

Jetzt müsste ich nur noch irgendwie eine Möglichkeit haben bestimmte Channels von VDR komplett zu ignorieren und nicht mehr hinzuzufügen. Aber selbst wenn es eine Lösung dazu gäbe, würde dies wohl auf Trial und Error hinauslaufen, bis ich alle problematischen Kanäle gefunden habe.

Edit: Es liegt wohl tatsächlich an bestimmten Channels. VDR lief jetzt die ganze Nacht ohne Probleme durch.

VG,
Zabrimus

Keine_Ahnung · 9. Oktober 2011

Was sagt den die BER auf diesen problematischen Kanälen? Weil es hat schon irgendwie den Eindruck das ein schlechter Empfang die Daten verwürfelt. Und wenn dann irgendwo nen Fehler nicht abgefangen wird...

cu

Zabrimus · 10. Oktober 2011

Vielleicht eine dumme Frage, aber wie kann ich denn die BER eines bestimmten Channels bestimmen?
Der Server läuft vollständig headless und dient als streamdev-server.

Zabrimus

micmac · 10. Oktober 2011

Hi!

Was hast du für einen Prozessor? In dem Trace is von CMOV die Rede. Manche i586 CPUs haben das nicht. Hast du vielleicht ein VIA Epia oder dergleichen?

Zabrimus · 10. Oktober 2011

In dem Rechner (der mehr als nur ein VDR-Server ist) steckt ein Core2Quad. Das System lief ja eine zeitlang recht problemlos und ich dachte schon daran live zu gehen und den Haushaltsvorstand damit zu beglücken. Nur wird die Frau an die Decke springen, wenn das Programm dauernd stockt *g*

Ich habe versuchsweise mal die alte channels.conf eingespielt und VDR neugestartet. Mit UpdateChannels = 0 schien es auch zu laufen. Femon ist auch installiert, aber die Ausgabe per svrdp (plug femon info) erschliesst sich mir irgendwie nicht.

Aber ich werde heute Abend noch ein paar Untersuchungen starten.

Wie kann ich denn eine Zuordnung von
cEIT (this=0xb2df7240, Schedules=0x818fa40, Source=1124073472, Tid=80 'P', Data=0xb2df7338 "P\362%Z@\331\300", <incomplete sequence \370>, OnlyRunningStatus=false)
oder
cEitFilter:: process (this=0xb6c33b88, Pid=18, Tid=80 'P', Data=0xb11f3338 "P\360qZ?׀", <incomplete sequence \370>, Length=116)
auf den oder die problematischen Channel machen? Geht das überhaupt?

Zabrimus

Hemonu · 10. Oktober 2011

Zitat von Zabrimus

Aber ich bin einen Schritt weiter. Mir ist aufgefallen, daß fast immer derselbe Kanal im Logfile zuletzt auftauchte, bei dem eine PID/Name-Änderung erfolgte. Bei mir war es Teleklub (DVB-C, Unitymedia)..

Nachdem ich diesen Kanal, alle ausländischen Kanäle und auch die Radiosender aus der channels.conf gelöscht habe (Paranoia pur) und in der setup.conf den Parameter UpdateChannels auf 0 setzte, läuft VDR nun schon seit phänomenalen 30 Minuten ohne Fehler.
Aktuell würde ich dies als Erfolg bezeichnen.

Ich habe das gleiche Problem. Zum ersten mal aufgetaucht am letzten Freitag, Samstag lief der VDR den ganzen Tag ohne Probleme, gestern wieder den ganzen Tag Absturz ca. alle zehn Minuten. Plugins aus, epg.data gelöscht, VDR neu installiert .. hat alles nichts gebracht. Ich habe ebenfalls Unitymedia (NRW). Das Signal ist bei mir ziemlich "auf der Kante". Nicht wegen Signalpegel sondern wegen hohem Intermodulationsniveau. Ich werde heute Abend mal testen, ob ich mit deinem Ansatz das Problem umschiffen kann.

Herbert

FireFly · 10. Oktober 2011

Zitat von Zabrimus

Wie kann ich denn eine Zuordnung von
cEIT (this=0xb2df7240, Schedules=0x818fa40, Source=1124073472, Tid=80 'P', Data=0xb2df7338 "P\362%Z@\331\300", <incomplete sequence \370>, OnlyRunningStatus=false)
oder
cEitFilter:: process (this=0xb6c33b88, Pid=18, Tid=80 'P', Data=0xb11f3338 "P\360qZ?׀", <incomplete sequence \370>, Length=116)
auf den oder die problematischen Channel machen? Geht das überhaupt?

Du kannst vor den entsprechenden Stellen isyslogs einbauen, die Dir dann die Infos in das syslog schreiben.

pet547 · 10. Oktober 2011

Auch ich habe Unitymedia und auch bei gibt es die gleichen Probleme. Habe ältere vdr-Images mit Acronis eingespielt die immer einwandfrei funktioniert haben -> auch hier die gleichen Abstürze. Ich habe dann die channels.conf auf 60 Einträge beschränkt und Parameter UpdateChannels auf 0 gesetzt. Seitdem läuft die Kiste seit mehr als 24 Stunden durch. Zufall? Ich weiss es nicht. Muss man weiter beobachten.

Hemonu · 11. Oktober 2011

Ich habe mich mal auf die Suche nach dem "Übeltäter" gemacht.

1. Nur Abschalten des Kanäle aktualisieren --> kein Änderung, Absturz nach je knapp 9 Minuten

2. Kürzen der channel.conf auf die wichtigsten Kanäle --> VDR läuft stabil

3. Ermitteln eines Kanals mit dem der Rechner abstürzt durch eine ziemlich zeitaufwändige Intervallschaltung mit den verdächtigen Kanälen.

Als Ergebnis hier ein Eintrag, der meinen VDR zum Absturz bringt:

Liberty TV;UnityDigitalTV:650000:C0M256:C:6900:533=2:534=fra@3:0:1831,1722,1801,1838,1835:28103:9999:281:0

Evt. gibt es aber noch weitere Einträge, die das Problem generieren. Ich werde morgen mal andere Programme des gleichen Transponders testen.

pet547: welche Distri setzt du ein?

hemonu

pet547 · 11. Oktober 2011

Meine Distri ist yaVDR-0.3 mit allen aktuellen Updates. Info: nach meiner Massnahme tritt kein Fehler mehr auf. Ich werde heute abend den channels.conf "Absturzeintrag" testen und berichten. Punkt 1 und 2 deines Beitrags ist bei mir genau so.

Zabrimus · 11. Oktober 2011

Ich hatte irgendwie das Gefühl, daß interne Datenstrukturen nicht valide sind oder werden.
Meine channels.conf habe ich fast vollständig gelöscht und nur noch einen Sender drin gelassen, der bei mir einen Fehler verursacht hatte um dann mittels valgrind bzw. vdrleaktest den VDR neu zu starten.

Recht schnell kam diese Meldung:

Code

==3341== Memcheck, a memory error detector
==3341== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3341== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3341== Command: /usr/bin/vdr-dbg -v /share/nfs/video -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -E /var/cache/vdr/epg.data -g /tmp -w 0 --userdump --port 6419 --lirc
==3341== 
vdr: error while reading '/var/lib/vdr/timers.conf'
vdr: no primary device found - using first device!
==3341== Thread 5:
==3341== Invalid write of size 4
==3341==at 0x813933B: SI::DescriptorGroup::Add(SI::GroupDescriptor*) (si.c:209)
==3341==by 0x80BEC65: cEIT::cEIT(cSchedules*, int, unsigned char, unsigned char const*, bool) (eit.c:140)
==3341==by 0x80BF97B: cEitFilter::Process(unsigned short, unsigned char, unsigned char const*, int) (eit.c:382)
==3341==by 0x810C762: cSectionHandler::Action() (sections.c:212)
==3341==by 0x8128AAF: cThread::StartThread(cThread*) (thread.c:257)
==3341==by 0x4058954: start_thread (pthread_create.c:300)
==3341==by 0x433EE7D: clone (clone.S:130)
==3341==  Address 0x7d6d4e0 is not stack'd, malloc'd or (recently) free'd

Alles anzeigen

Ob dies allerdings die Ursache ist, kann ich nicht sagen...

Edit:
Ein kleine Änderung in der entsprechenden Methode - sprich eine Ausgabe ergab folgendes:

Code

void DescriptorGroup::Add(GroupDescriptor *d) {
   if (!array) {
  length=d->getLastDescriptorNumber()+1;
  array=new GroupDescriptor*[length]; //numbering is zero-based
  for (int i=0;i<length;i++)
     array[i]=0;
   } else if (length != d->getLastDescriptorNumber()+1)
  return; //avoid crash in case of misuse


   if (length <= d->getDescriptorNumber()) {
	printf("-- Length %d, Index %d, Last %d\n", length, d->getDescriptorNumber(), d->getLastDescriptorNumber());
  }


   array[d->getDescriptorNumber()]=d;
}

Alles anzeigen

-- Length 1, Index 6, Last 0
-- Length 1, Index 6, Last 0
-- Length 1, Index 6, Last 0
-- Length 1, Index 6, Last 0

Warum das passiert, kann ich nicht sagen, allerdings prüfe ich mal, was passiert, wenn ich solche Werte einfach ignoriere.

Zabrimus

vdrchuck · 11. Oktober 2011

Hi,

ich kann jetzt nicht helfen bezüglich Sourcecode....., aber evtl. etwas hiermit zu tun !?

http://www.mail-archive.com/vdr@linuxtv.org/msg14775.html

Code

2011-09-04: Version 1.7.21
...
- The new function cDevice::ProvidesEIT() is used to determine whether a device can
provide EIT data and will thus be used in cEITScanner::Process() to receive EIT
data from the channels it can receive (suggested by Rolf Ahrenberg). Note that by
default it is assumed that a device can't provide EIT data, and only the builtin
cDvbDevice returns true from this function.

Gruß,
Chuck

Zabrimus · 11. Oktober 2011

Die geänderte Variante scheint ohne Abstürze zu laufen. (UpdateChannels=5 und wieder die volle channels.conf)

Diff

--- ./vdr-1.7.21/libsi/si.c 	2011-10-11 21:18:33.518485148 +0200
+++ vdr-1.7.21-patched/libsi/si.c   	2011-10-11 21:18:50.798485140 +0200
@@ -206,6 +206,13 @@
      	array[i]=0;
	} else if (length != d->getLastDescriptorNumber()+1)
   	return; //avoid crash in case of misuse
+
+   if (length <= d->getDescriptorNumber()) {
+  	return;
+   }
+
	array[d->getDescriptorNumber()]=d;
 }

Alles anzeigen

Meine aktive C-Sturm und Drangzeit liegt schon einige Jahre zurück und vielleicht gibt es auch eine bessere Lösung. Schöner wäre es natürlich die Ursache zu beseitigen, anstatt an den Symptomen rumzudoktorn.

Was immer auch EIT ist, aber es scheint einen Zusammenhang zwischen den Abstürzen und den Änderungen zu geben. Vielleicht werden jetzt ein paar Sender mehr gescanned, als vorher. Dies würde zumindest den Workaround mit der Kürzung der channels.conf erklären. Aber da sollten Experten lieber ein Auge drauf werfen.

Edit:
Der VDR lief die ganze Nacht ohne Probleme durch.

Zabrimus

Zabrimus · 15. Oktober 2011

Zur Info:
Das Problem trat bei mir auch auf einem VDR-Client-Only Rechner (streamdev-client) auf. Zuerst hatte ich eine oder mehere Aufnahmen im Visier, aber nach einspielen des Patches trat auch hier eine Besserung auf.

Zabrimus

Paule99 · 15. Oktober 2011

Hi,

ich hatte heute mittag auch plötzlich alle 5-10min segfaults, gegen Abend wurde es deutlich besser. Kabelanbieter ist ebenfalls Unitymedia, nach einspielen des Patches scheint nun alles ok zu sein.
Gut möglich dass die Abstürze schon seit 1Woche tagsüber auftreten, jedenfalls musste ich abends, nach der Arbeit, das Xine-UI neu verbinden (hab mir dabei nichts gedacht und fällt mir auch jetzt erst, im Zusammenhang mit diesem Thread, wieder ein). Damit passt das zeitlich mit den hier geschilderten Problemen überein.
Im Einsatz habe ich VDR 1.7.18, ich denke daher daß eine Änderung seitens UM der Auslöser sein könnte und nicht die neue EIT Funktion.

Gruß
Jens

mark05 · 16. Oktober 2011

hi

habe den fehler auch ebenfalls unitymedia und dvb-c

cpu ist ne core2duo .

vdr 1.7.21

e-tobi packete und debian squeeze.

habe mal die channels gekuerzt und updatechannels auf 0 gesetzt.

mal sehen ob es nun stabiler ist.

holger

mark05 · 16. Oktober 2011

hi

zz laeuft es stabil

jetzt erscheint im lg auch wieder

Code

saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer

holger

gromit · 19. Oktober 2011

Hi @all,
bin zufällig auf diesen Thread gestossen, obwohl ich kein c't vdr,
sondern einen selbst kompilierten vdr-1.7.18 auf open suse 11.4 habe.
Habe Unity Media aber (mit vdr-1.7.18) bisher keine Abstürze.

Seit Ihr sicher, dass der Absturz nicht von einem Plugin kommt?
Hat das mal wer getestet?

Ansonsten würde ich mal Klaus auf das Problem aufmerksam machen,
er kann bestimmt Tipps geben ob es einen besseren Patch gibt.

von Zabrimus

Zitat

Was immer auch EIT ist, aber es scheint einen Zusammenhang zwischen den Abstürzen und den Änderungen zu geben.

aus libsi/headers.h

Zitat

* 3) Event Information Table (EIT):
*
* - the EIT contains data concerning events or programmes such as event
* name, start time, duration, etc.; - the use of different descriptors
* allows the transmission of different kinds of event information e.g.
* for different service types.

Alles anzeigen

cu gromit

Segfault mit VDR 1.7.21

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema