1.6er Segfaults ohne Ende

bei mir läuft die 1.6.0-1 stabil und zuverlässig inkl. UTF8, habe aber auch alles selbst compiliert (unter opensuse 10.2/10.3).

Core-dumps werden im "aktuellen Verzeichnis" abgelegt, also in dem Verzeichnis, das gerade aktiv war als VDR gestartet wurde.
Irgendwann hatte ich mir mal hier aus einem Forenbeitrag folgendes gegreppet:

Zitat

Autor unbekannt
- ulimit -c unlimited eingeben (an der Konsole an welcher du den VDR Startest, oder oben ins runvdr Skript schreiben)
- vdr neu starten
- den von dir beschriebenen Absturz herbeiführen
- das core File suchen (core oder core.<pid>) wenn es mehrere gibt, dann das mit dem aktuellen Datum
- gdb <pfad zum vdr>/vdr <pfad zum corefile>/<name des corefile> eingeben
- an den gdb promt bt eingeben
- die Ausgabe hier posten

Alles anzeigen

Du kannst aber auch "gdb /usr/bin/vdr" eingeben (oder wo das Executable liegt) und dann am gdb-Prompt "run -L <libDir> -Pskinelchi -Pavards -Premote ..." eingeben, also hinter run alle Parameter anhängen und dann beim Absturz direkt mit bt einen Backtrace anzeigen lassen.

Wenn Du zwei core-files hast, ist das dann ein Dual-Core? (sorry, couldn't resist)

Pff, ach, mit diversen Plugins schmiert dir dein VDR ständig ab?
Na, dann probiere doch erstmal den "vanilla" VDR - das wäre zumindest das, was ich dir als Entwickler sagen würde.

Gruß,
Juri

PS: bei mir läuft VDR 1.6.0 mit ca. 10 Plugins stabil - kein Absturz bisher ( ~1 Monat intensive Nutzung)

Zitat

Original von FireFly
bei mir läuft die 1.6.0-1 stabil und zuverlässig inkl. UTF8, habe aber auch alles selbst compiliert (unter opensuse 10.2/10.3).

Hast Du zufällig auch unter den Plugins das ffnetdev und/oder statusleds Plugin? Mit diesen zwei Plugins habe ich beim Herunterfahren des VDR auch immer Segfaults (siehe Posting hier)?

Wenn ja, wäre ich an den Sourcen/Downloadquellen interessiert - sonst muss ich wohl im Board nochmal fragen, ob das jemand stabil am laufen hat.

Danke & Gruss
Marcus

Zitat

Original von dad401
beim Herunterfahren des VDR auch immer Segfaults

Probleme beim Beenden von vdr gibt (gab?) es auch mit pvrinput, wobei zumindest bei mir das Auskommentieren eines isyslog-Aufrus in vdr.c die Probleme beendet hat:
debuggen: Kennt sich jemand mit GDB aus?

Ich hab aber von einem user Rückmeldungen, dass er noch immer segmentation faults beim Beenden hat.

@thread titel
ich glaub eher dass einige plugins noch probleme mit 1.6 haben
bei mir "segfaulted" z.b das sleeptimer plugin
ansonsten laeuft bei mir vdr 1.6 (etobi) unter debian etch wunderbar

... ich habe die segfaults beim Beenden des VDR längst als "gegeben" hingenommen. Ich kann auch keine Probleme dadurch feststellen; der eine Logeintrag mehr macht den Kohl nun auch nicht fett.

Gruß
Holger

Zitat

Original von dad401
Hast Du zufällig auch unter den Plugins das ffnetdev und/oder statusleds Plugin?

Nee, sorry, die benutze ich nicht.
Habe aber auch schon Probleme mit graphlcd gehabt und musste da ne Variable auf NULL setzen (falls das bzw. den Patch jemand interessiert...)
Wenn die Tage Zeit habe (und auch noch Lust dazu) versuche ich mal das statusled anzupassen und poste es dann ein deinem anderen Thread, ne Idee dazu habe ich schon, denn wie bei so viele Plugins werden selbst erzeugt Threads beim Beenden von VDR nicht gestoppt und dann kracht es halt beim Shutdown.

FireFly
PS: ich liebe Plugins, die nur aus einer Datei bestehen (zzgl. Übersetzung)

Zitat

Original von FireFly
wie bei so viele Plugins werden selbst erzeugt Threads beim Beenden von VDR nicht gestoppt und dann kracht es halt beim Shutdown.

mag ja sein, dass einige Plugins Stop() nicht richtig implementiert haben und Threads nur über den Destructor beenden. So richtig deutlich finde ich die PLUGINS.html aber auch nicht: wann ist ein vom Plugin gestarteter Thread ein Hintergrund-Prozess?

und warum lief das jahrelang mit vdr 1.4 problemlos?
Was hat sich bei vdr 1.6 so gravierend verändert, und wo findet man eine Dokumentation, was konkret an den Plugns geändert werden muss?

Na, ich hatte das auch schon bei 1.4. Auf der anderen Seite: graphlcd ist da immer gelaufen, jetzt mit 1.6 musste ich plötzlich im Konstruktor ein Pointer mit NULL initialisieren (sollte man ja sowieso) weil es sonst abgestürzt ist.
Evtl. ist die 1.6 da empfindlicher geworden? Oder die Rechner schneller bzw. haben mehr (>1) Kerne als früher und deshalb kommen die Probleme erst jetzt zum tragen? (Glaskugelmodus wieder aus :))

Was auch oft passiert, ist dass zu schnelle beenden des VDR: erst ein kill -15 und nur 2-3 Sekunden danach ein kill -9, das langt aber gerade bei vielen geladenen Plugins nicht. Ich habe da jetzt einen Timeout von 12 Sekunden eingestellt und keine Probleme mehr (siehe killproc von suse).

Zitat

Original von FireFly
Habe aber auch schon Probleme mit graphlcd gehabt und musste da ne Variable auf NULL setzen (falls das bzw. den Patch jemand interessiert...)

Ich bin schon etwas neugierig und würde gerne wissen welche Variable Du
auf NULL setzen musstest. Welche Version des Plugins hast Du gepatched?
Ich möchte gerne mit eigenen Augen sehen warum das hilft.

Gerald

gda:

Komisch, das sollte eigentlich nur bis zum Start von

bool cPluginGraphLCD::Initialize()

eine Rolle spielen, dann wird mDisplay sowieso
überschrieben.
Ein Problem gibt es nur wenn aus irgendwelchen Gründen

void cPluginGraphLCD::MainThreadHook() {     if (mDisplay)         mDisplay->Tick(); }

vorher ausgeführt wird.
Das sollte dann aber nicht erst beim Shutdown ein Problem sein.
Oder wird

void cPluginGraphLCD::MainThreadHook

erst beim Shutdown ausgeführt? Vielleicht sehe ich mir das die nächsten
Tage näher an.

Gerald

Zitat

Original von gda
Das sollte dann aber nicht erst beim Shutdown ein Problem sein.

Ja, ich glaube, er ist damals direkt beim Start abgebröselt. Ich habs ziemlich schnell gefixed und mir deshalb keine weiteren Gedanken gemacht.