[0.5] Live verursacht manchmal Absturz

Sowas hatte ich unter Debian auch schon öfter. Hatte mal die Vermutung, das passiert, wenn man irgendwelche Systmlibs aktualisert und den VDR danach nicht neu kompiliert.

Aber da hilft wohl nur mal Debuggen.

Bei mir passiert das nicht (mehr). Nachdem das neulich mal bei mir passiert ist, hab ich den VDR komplett neu kompiliert, weil ich vor ein apt-get upgrade bei mir gemacht habe und dachte, dass es eventuell daran liegt.

Werds mal beobachten.

Das Paket vdr-dbg bringt die Symbole und ein Script mit, welches ein Crashlog mit Backtrace unter /var/log/vdr erstellt.
Das könnte auch helfen.

Von einigen Plugins gibt es auch dbg-Pakete, die könnte man auch noch installieren.

Lars.

Hi!

Ich habe bei mir jetzt auch sporadisch das Problem (benutze testing), allerdings nicht immer und bei mir kommt es auch schon, wenn ich einmalig auf Timer gehe und nicht mehrmals die Seite neu lade.

Nov  9 11:50:37 yavdr kernel: [82203.819057] traps: vdr-dbg[26805] general protection ip:7fd36668a99f sp:7fd34b7f6ad8 error:0 in libc-2.15.so[7fd366550000+1b5000]

Trotz installiertem vdr-dbg und vdr-plugin-live-dbg wird leider kein Backtrace in der crashlog erzeugt, es wird nur ein Core abgelegt. Ziemlich nervig die Situation, ich compiliere jetzt auch mal den VDR neu und beobachte dann mal weiter, aber das kann ja irgendwie auch nicht die Lösung sein...

Wenn ein core abgelegt wird, versucht doch mal ein "gdb vdr core" in dem Verzeichnis.

Ich hatte das Problem auch diverse male. Hab dann einen bt erstellen wollen, aber seit dem trat es nicht mehr auf.

Guter Hinweis, ich Dussel hatte das gdb Paket gar nicht installiert, daher kein crachlog

Scheint ja irgendwas mit LongDescription zu sein. Weisst Du noch, wie die LongDescription bei dem Timer aussah?

Hab die Aufnahme leider nicht mehr, da ich zur Zeit am testen bin auf der Maschine...

Hab auch mal wieder so einen Fall:

Program terminated with signal 11, Segmentation fault.
#0  __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
32	../sysdeps/x86_64/multiarch/strlen-sse4.S: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
#1  0x00007fc8da0be450 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007fc8d315f008 in vdrlive::EpgEvent::LongDescr (this=<optimized out>) at epg_events.h:176
#3  0x00007fc8d31aa64f in (anonymous namespace)::_component_::operator() (this=0x5a09ee0, request=..., reply=..., 
    qparam=...) at timers.ecpp:89
#4  0x00007fc8d2ed5d67 in tnt::Worker::dispatch(tnt::HttpRequest&, tnt::HttpReply&) () from /usr/lib/libtntnet.so.10
#5  0x00007fc8d2ed7833 in tnt::Worker::processRequest(tnt::HttpRequest&, std::iostream&, unsigned int) ()
   from /usr/lib/libtntnet.so.10
#6  0x00007fc8d2ed87a7 in tnt::Worker::run() () from /usr/lib/libtntnet.so.10
#7  0x00007fc8d2ed960a in cxxtools::DetachedThread::exec() () from /usr/lib/libtntnet.so.10
#8  0x00007fc8d2bf9d3f in ?? () from /usr/lib/libcxxtools.so.8
#9  0x00007fc8dadf0b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#10 0x00007fc8d98b5a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Es muss mit bestimmten Timern zu tun haben, bei denen irgendwas ungewöhnliches in der LongDescription enthalten ist.

virtual std::string const LongDescr() const { return std::string(m_event->Description() ? m_event->Description() : ""); }

Hier mal das Event

E 291967 1384980600 3000 50 FF
T American Horror Story
S Bitchcraft
D Genre: Horror|Kategorie: Serie|Land: USA|Jahr: 2013|||[Tipp]||Die junge Zoe Benson  erfährt, dass sie eine Hexe ist. Im Hexeninternat lernt sie, ihre Kräfte zu meistern. Doch Feinde machen Jagd auf sie.||Originaltitel: American Horror Story||Darsteller: Kathy Bates (Madame LaLaurie), Angela Bassett (Marie Laveau), Jessica Lange (Fiona), Taissa Farmiga (Zoe Benson)||Regie: Alfonso Gomez-Rejon|Audio: Stereo|Flags: [16:9] [Neu]||Quelle: DVB/TVM
R 16
e

Erstaunilicherweise gehts, nachdem der VDR neugestartet ist. Woran könnte das liegen @C++ Profis?

Ein falsch kodiert Unicode-String? Oder es ist eine race condition, weil das cEvent vom vdr mittlerweile entsorgt wurde?
Ich weiß jetzt gerade nicht, ob live sich eine lokale Kopie des cEvent-Objektes anlegt, vielleicht sollte man das mal versuchsweise machen.

Ich würde vermutlich im vdr in epg.c im Konstruktor und Destruktor von cEvent einfach Logmeldungen mit dem this-Pointer machen (%p) und dann beim Absturz nachsehen, ob das Ding nicht schon zerstört wurde.

Lars.

Zitat von mini73

Oder es ist eine race condition, weil das cEvent vom vdr mittlerweile entsorgt wurde?

oder eben in Zeiten hochintelligenter EPG Lösungen einfach nur ersetzt...

Graphtft hat an der Stelle auch noch eine kleine Schwäche - daher tendiere ich in Richtung von Lars

Christian

Zitat von CKone

oder eben in Zeiten hochintelligenter EPG Lösungen einfach nur ersetzt...

ist das gleiche, wenn das Objekt nicht mehr an der ursprünglichen Adresse existiert.

Ich bin mitterweile der Ansicht, dass man "flüchtige" Objekte des vdr wie Aufnahmen, Timer und Events sich niemals merken darf - nur an den Stellen, wo es Absicht ist, wie z.B. im EpgHandler (da muss man sich einen Pointer ja aber auch nicht merken, den bekommt man ja übergeben). Wenn im Plugin eine Funktion vom vdr aufgerufen wird, wo so ein Objekt übergeben wird und man länger gut davon haben will, dann muss man es sich kopieren (bzw. die relevanten Informationen daraus).

Die Events bzw. cSchedules bieten immerhin ein Lock, so dass der vdr weiß, dass da gerade jemand die Daten liest, das muss man natürlich benutzen. Aber auf cEvent-Objekte darf man nur innerhalb des Locks zugreifen. Und Locks müssen naturgemäß so kurz wie möglich und so lang wie nötig sein.

Bei den Aufnahmen (arbeite gerade an anderer Stelle damit, Stichwort recsearch) gibt es leider (noch?) keine Lock-Möglichkeit, weshalb man immer seine eigene Aufnahmenliste verwalten muss. Dann wird das Aufnahmeverzeichnis evtl. mehrmals von verschiedenen Nutzern gescannt, aber jedenfalls hat man dann die Kontrolle über seine Objekte.

Timer hab ich mir noch nicht weiter angeschaut.

Lars.

Das übersteigt meine Fähigkeiten, so dass ich auf eine Lösung warten muss. Ärgerlich ist das ganze nur dann, wenn gerade eine Aufnahme läuft und sich der VDR deshalb verabschiedet.

Ja, das ist es. Ich kann noch nicht genau sagen, wann ich dazu komme, mir das anzusehen.
Es wäre mir lieber, der Maintainer des Plugins würde das tun, der kennt es sicherlich besser.

Lars.

aber ist doch Mittwoch Lars?

Christian

Ja, aber ddbridge und recsearch fordern auch ihre Zeit.

Lars.

ich reihe mich mal in die Reihe der wartenden ein..;-)