[gelöst] [vdr 2.1.8+] Segfault seit eit_memleak-patch

acb321 · 7. Februar 2015

Hallo zusammen,
nachdem ich soeben in meinen Desktop-Rechner eine Sat-Karte gebaut habe bricht VDR mit einem Segfault ab, sobald auf einen DVB-S-Kanal geschaltet wird. Es handelt sich um eine (recht alte) Technisat Skystar 2 (b2c2-flexcop-pci aus Debian Kernel 3.16.0-4).

Mit 2.1.8 läuft das System rund, nachdem der pre-1 Patch eingespielt wurde nicht mehr. Mit Das Erste HD, welchen die SkyStar nicht wiedergeben kann, startet der VDR zumindest. Schaltet man auf einen DVB-S-Kanal um führt dies zu einem Speicherzugriffsfehler. Steht der letzte Kanal auf z.B. RTL bricht VDR sofort beim Start ab. Ich habe daraufhin den pre-1 Patch wieder herausgenommen und wollte die Komponenten einzeln nacheinander integrieren. Bereits der erste Teil ([PATCH] Memory leak im EIT Scanner bei kaputtem EPG) führte wieder zu den Abstürzen.

Hier der Backtrace von gdb

Code

(gdb) bt
#0 0x00007f00e40008d0 in ?? ()
#1 0x0000000000518c5c in SI::DescriptorGroup::Delete (this=0x7f00e4000af0) at si.c:196
#2 0x0000000000518ca5 in SI::DescriptorGroup::~DescriptorGroup (this=0x7f00e4000af0, __in_chrg=<optimized out>) at si.c:189
#3 0x000000000049ce57 in ~ExtendedEventDescriptors (this=0x7f00e4000af0, __in_chrg=<optimized out>) at libsi/descriptor.h:51
#4 cEIT::cEIT (this=0x7f00fb1a2d60, Schedules=<optimized out>, Source=<optimized out>, Tid=<optimized out>, Data=<optimized out>, OnlyRunningStatus=<optimized out>) at eit.c:289
#5 0x000000000049d868 in cEitFilter::Process (this=<optimized out>, Pid=<optimized out>, Tid=<optimized out>, Data=0x7f00fb1a2e70 "P\364Y/\b\337x\370\004A", Length=<optimized out>) at eit.c:394
#6 0x00000000004ea69c in cSectionHandler::Action (this=0x14fc8f0) at sections.c:212
#7 0x000000000050ca2f in cThread::StartThread (Thread=0x14fc8f0) at thread.c:262
#8 0x00007f010016c0a4 in start_thread (arg=0x7f00fb1a4700) at pthread_create.c:309
#9 0x00007f00fe962ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Alles anzeigen

Es wurden sonst keine Patches integriert. Der Test gab mit xineliboutput und komplett ohne Plugin (=>ohne Ausgabedevice) das gleiche Ergebnis.
Weitere Eingabedevices gibt es nicht, bisher wurde der VDR nur zum schauen und schneiden von Aufnahmen verwendet.

dvbsddevice wird doch soweit ich weiß nur für FF-Karten bzw. die Ausgabe benötigt(?). In einem anderen VDR mit TT S2-6400 läuft vdr-2.1.8 mit besagtem Patch einwandfrei.

Clemens

kls · 7. Februar 2015

Der Patch sieht so harmlos aus, ich kann mir fast nicht vorstellen, daß der solche Auswirkungen haben sollte.

Kannst du testweise mal in DescriptorGroup::Add() an den beiden 'return false' Stellen stattdessen 'true' zurückgeben? Damit sollte es sich wieder genauso verhalten wie vorher, halt nur mit dem geänderten Interface.

Klaus

acb321 · 8. Februar 2015

Hallo Klaus,
erstmal Entwarnung für die nächste Stable.

Vor dem Test wollte ich das ganze nochmal mit false reproduzieren und dann klappte es plötzlich. Der einzige Unterschied war, ich hatte zwischenzeitlich ein make distclean gemacht. Die Zeitstempel im Sicherungsordner zeigen, dass das Problem nicht im C-Code, sondern im Makefile steckt:

Code

$ ls -la vdr eit.* libsi/si.* libsi/libsi.a 
-rw-r--r-- 1 acb321 staff   19368 Feb  4 22:05 eit.c
-rw-r--r-- 1 acb321 staff 	501 Jan  3  2010 eit.h
-rw-r--r-- 1 acb321 staff  263912 Feb  4 22:05 eit.o
-rw-r--r-- 1 acb321 staff 2102478 Feb  1 20:49 libsi/libsi.a
-rw-r--r-- 1 acb321 staff   24066 Feb  4 22:05 libsi/si.c
-rw-r--r-- 1 acb321 staff   22589 Feb  4 22:05 libsi/si.h
-rw-r--r-- 1 acb321 staff  500368 Feb  1 20:49 libsi/si.o
-rwxr-xr-x 1 acb321 staff 6271920 Feb  4 22:05 vdr

Das ist der Inhalt nach einem "make all" im Hauptverzeichnis. Wie man sieht wurde die libsi/si.o nicht aktualisiert, daher auch nicht die libsi.a.
Die bisher von mir genutzten Patche haben nur die eigentlichen VDR-Daten angefasst, daher genügte ein einfaches make immer.

Führt man im Unterordner libsi ein "make all" aus werden die Dateien aktualisiert. Ein anschließendes make im Hauptordner macht den Rest.
Nebenbei: Nur "make" genügt unter libsi nicht, dann wird nur die utils.o (erstes Element der OBJS) aktualisiert bzw. geprüft.

Zumindest mit dem vollständigen pre-1 Patch funktioniert es nun. ~~Morgen~~ gleich mal sehen was die 2.1.9 sagt.

Danke für deine Mühen!

Clemens

kls · 8. Februar 2015

Da bin ich aber froh, daß das doch noch eine Erklärung gefunden hat.

Mir fällt leider auch keine saubere Lösung dafür ein, bei einem "make all" (oder auch nur "make vdr") im Hauptverzeichnis automatisch ein eventuell nötiges Neuübersetzen im "libsi"-Verzeichnis anzustoßen. Dazu müsste ja das VDR-Makefile wohl die Abhängigkeiten innerhalb des "libsi"-Makefiles kennen, was ich aber gerne vermeiden würde.

Vielleicht weiß ja ein "Makefile-Guru" hier, wie man das einfach und sauber hinbekommen könnte...

Klaus

TheChief · 8. Februar 2015

Was macht denn make all und make vdr?

Bei mir hat bisher immer ein "make clean && make clean-plugins && make" ausgereicht, um VDR und Plugins neu zu bauen.

Oder ist das abhängig, auf welchem System man baut?

kls · 8. Februar 2015

Wenn du vorher "make clean" machst gibt es kein Problem.
Das Problem besteht nur dann, wenn man im "libsi"-Verzeichnis etwas ändert und dann im VDR-Verzeichnis einfach nur "make" macht, ohne vorheriges "clean" (bzw. vorheriges "make" innerhalb des "libsi"-Verzeichnisses). Das Makefile prüft zwar die Abhängigkeit von libsi/libsi.a, aber nicht, ob libsi.a selber aktuell ist.

Klaus

acb321 · 8. Februar 2015

Je nachdem wie viel im Code geändert wurde und wie viele Plugins hinterlegt sind gibt es schon eine ziemlichen zeitlichen Vorteil nur make laufen zu lassen ohne vorher alles bereits erledigte wegzuschmeißen.
Das ist normalerweise auch der erste Schritt wenn etwas nicht funktioniert - war gestern wohl doch zu spät.

Hiermit würde es zumindest für make bzw. make all funktionieren. Für make vdr würde es nicht genügen. Wenn man da auch auf das virtuelle "build-$(SILIB)" verweisen würde dann würde die vdr-binary immer neu gebaut werden.
Eine andere Idee hätte ich nicht, aber ich bin auch sicherlich kein makefile-guru

Clemens

kls · 8. Februar 2015

Da bin ich irgendwie nicht so begeistert davon, weil es zum einen die Zeile für den Make-Aufruf für libsi vollständig dupliziert, und zum anderen das Problem nicht vollständig löst.
Eine vollständige Lösung müsste schon bei "make vdr" greifen, alle anderen Targets ergeben sich dann ja von selber.
Aber vielleicht muss man damit halt einfach leben. So oft ändert sich libsi ja nicht...

Klaus

S:oren · 8. Februar 2015

Ich wuerde es so machen:

Diff

--- Makefile.orig	2015-02-08 16:25:44.898472463 +0100
+++ Makefile	2015-02-08 17:59:36.229817886 +0100
@@ -137,10 +137,11 @@ $(DEPFILE): Makefile
 vdr: $(OBJS) $(SILIB)
 	$(CXX) $(CXXFLAGS) -rdynamic $(LDFLAGS) $(OBJS) $(LIBS) $(SILIB) -o vdr
 
-# The libsi library:
+# The libsi library (add dependency to nonexistet file -> always call sub-make):
 
-$(SILIB):
+$(SILIB): make-libsi
 	$(MAKE) --no-print-directory -C $(LSIDIR) CXXFLAGS="$(CXXFLAGS)" DEFINES="$(CDEFINES)" all
+make-libsi:
 
 # pkg-config file:

Alles anzeigen

Gruss,
S:oren

Edit: Wahrscheinlich haette es ausfuehrlicher "add dependency to nonexistent file with empty make rule -> always call sub-make" heissen muessen...

kls · 9. Februar 2015

Das sieht zwar auf den ersten Blick vielversprechend aus, und tut auch das, was es soll.
Aber wenn alles aktuell ist und man macht

make vdr

dann kommt nicht mehr

make: 'vdr' is up to date.

sondern

make[1]: Nothing to be done for 'all'.

Gut, wenn man

make plugins

macht und alles ist aktuell, dann kommt auch

*** Plugin dvbhddevice:
make[1]: Nothing to be done for 'all'.
*** Plugin dvbsddevice:
make[1]: Nothing to be done for 'all'.
*** Plugin epgtableid0:
make[1]: Nothing to be done for 'all'.
*** Plugin hello:
make[1]: Nothing to be done for 'all'.
...

insofern ist das vielleicht auch nicht so schlimm. Der Vorteil, daß garantiert immer neu übersetzt wird, wenn es nötig ist, überwiegt hier wohl.

Weiß vielleicht noch jemand, wie man diese "make[1]: Nothing to be done for ..." Meldungen unterdrücken könnte?

Klaus

S:oren · 9. Februar 2015

Zitat von kls

Weiß vielleicht noch jemand, wie man diese "make[1]: Nothing to be done for ..." Meldungen unterdrücken könnte?

Vielleicht so?

Gruss,
S:oren

[gelöst] [vdr 2.1.8+] Segfault seit eit_memleak-patch

Jetzt mitmachen!

Teilen