Abstürze (nicht durch controld-zapit-merge!) >> Fehlersuche

[rhabarber1848]

Auf dreambox läuft es aber problemlos, oder hat da auch jemand Probleme ?

Schnellere CPU, welche die race-condition verhindert?
Hier geht es um schnelles Umschalten, was man schon
fast als Dbox-Quälerei bezeichnen kann

[-=HSKc=-Robby]

Fast alles, besonders

Code: Alles auswählen

until neutrino -f -u ; do
    echo "Neutrino exited with nonzero exit status, restarting..."

Achje, solche Unterschiede hätte ich nicht erwartet...

Hab mir grad nen DietmarW-jffs2-Image von gestern runtergeladen und da mit NewTuxFlash rein geschaut. Ist die dortige der CVS-Standart? Dann werd ich mir die mal aufs JtG anpassen

Hier geht es um schnelles Umschalten, was man schon
fast als Dbox-Quälerei bezeichnen kann

Also die Abstürze kommen nicht nur beim schnellen Umschalten

[re_Look]

@rhabarber1848
Da kannst du recht haben.

Noch eine Idee.
Vielleicht reicht es in infoviewer.cpp die Priorität hoch zu setzen ?
g_RCInput->postMsg(msg, (const neutrino_msg_data_t)_info, false );
und
g_RCInput->postMsg(NeutrinoMessages::EVT_NOEPG_YET, (const neutrino_msg_data_t)p, false); // data is pointer to allocated memory

Von false auf true.

[rhabarber1848]

Ist die dortige der CVS-Standart?

Wahrscheinlich, die CVS-Datei findest Du hier:
http://cvs.tuxbox-cvs.sourceforge.net/c ... iew=markup

Hier geht es um schnelles Umschalten, was man schon
fast als Dbox-Quälerei bezeichnen kann

Also die Abstürze kommen nicht nur beim schnellen Umschalten

Ich konnte es nur so reproduzieren, hast
Du eine fingerschonende Alternative?

[-=HSKc=-Robby]

Ich konnte es nur so reproduzieren, hast
Du eine fingerschonende Alternative?

Nur mit Gedult , irgendwann stürzt es halt bei nem zap-Versuch ab...

btw: im DietmarW ist die CVS-start_neutrino

[seife]

rhabarber: dann check doch das revertete erstmal ein, damit es wieder für alle geht.

re_look: auf der TD tritt es auch nicht auf, die ist auch so schnell wie die dreambox. Und auf der TD tritt es auch im valgrind nicht auf, da ist dann wieder alles viel zu langsam ;-)

Das mit der High-prio queue könnte helfen, ich bin mir aber nicht sicher, ob es das problem nicht nur maskieren würde.

[rhabarber1848]

rhabarber: dann check doch das revertete erstmal ein, damit es wieder für alle geht.

Erledigt: http://cvs.tuxbox-cvs.sourceforge.net/c ... 6&r2=1.257

[Houdini]

kann man den Speicher nicht in der Funktion gleich wieder freigeben?
Sowohl _info als auch p sollten doch außerhalb nicht benutzt werden, das postMsg / write überträgt doch die pointer gar nicht,
oder bin ich da jetzt off sync?

[-=HSKc=-Robby]

Hab im JtG-Forum mal die angepasste start_neutrino gepostet. Falls da jemand was mit anfangen kann

[Houdini]

so, also den Speicher kann man nicht gleich freigeben...
Das Problem liegt wohl daran, das bein new(cn_info) die string objekte anders alloziert/initialisiert werden
so daß beim string kopieren in CRemoteControl::handleMsg (CLCD::getInstance()->setEPGTitle(info_CN->current_name);) da nichts in die Hose geht.

[seife]

Houdini: das ganze ist noch etwas komplizierter. Es geht nämlich nur in die Hose, wenn meherere events in die Queue geposted wurden vor das erste abgearbeitet wurde. Und obwohl da definitiv verschiedene adressen übergeben werden geht irgendwo was schief.

Ich vermute einen der default- "if msg > withdata, dann delete[] char* data"- "deallozierer", der aufgerufen wird ohne dass die daten verarbeitet wurden. Später werden die daten dann verarbeitet, sind aber nicht mehr wirklich vorhanden. Oder so.

Ich werde das versuchen so zu "lösen", dass ich einfach _keine_ daten mit über den socket jage, denn wenn getEPG() aufgerufen wird (der einzige Platz, an dem so ein event erzeugt wird), dann ist das current-epg ja schon bekannt.

Dumm ist, dass es bei mir nicht auftritt, drum ist das alles eine ziemliche Raterei meinerseits.

[rhabarber1848]

Dumm ist, dass es bei mir nicht auftritt

Hast Du es schon auf einer Dbox probiert?

[seife]

Nicht wirklich

Das Problem ist, dass mein bevorzugtes Tool um solche Fehler zu suchen (valgrind) auf meiner dbox nicht einsetzbar ist. Andererseits wäre mir evtl. mit ein paar strategischen printf's auch geholfen, insofern hast du recht: muss ich mal machen. Nur bis ich wieder das Yadd aufgesetzt habe etc....

[-=HSKc=-Robby]

Kann eventuell die Community was dazu sagen, ob der Fehler auf allen D-Boxen auftritt? Ich hab es bisher nur bei zwei Nokia Avia600 Boxen gehabt. Bei meiner Sagem ist es noch nicht aufgetreten

[rhabarber1848]

Bei meiner Sagem ist es noch nicht aufgetreten

Ich besitze nur eine Sagem und konnte den Bug dort problemlos reproduzieren.

[-=HSKc=-Robby]

Ich besitze nur eine Sagem und konnte den Bug dort problemlos reproduzieren.

Dann hab ich wohl mit meiner Sagem nur "Glück" gehabt...

btw: die an (Deinen) CVS-Standart angepasste start_neutrino ist eine echte Verbesserung fürs JtG-Image, hoffe Riker übernimmt die Anpassungen

[seife]

Ich konnte es auf meiner Philips/Kernel 2.6 nicht reproduzieren.
Egal, ich habe eine Vermutung, woran es liegt und eine Lösung / Workaround: infoviewer-currentnext-rework.diff
Bitte testen.

Woran liegts (meiner Meinung nach)?
Nun, das "char * foo = new char[sizeof(CSectionsdClient::CurrentNextInfo)];" und späteres hineinkopieren einer CSectionsdClient::CurrentNextInfo mittels memcpy kann vermutlich so nicht funktionieren, da ja im CSectionsdClient::CurrentNextInfo z.B. zwei std::string mit drin sind, die ja keine fixe Grösse haben. Damit ist vermutlich schon alles gesagt, die Frage ist wohl, warum es mir nicht schon viel früher um die Ohren geflogen ist

Die Lösung ist einfach: ich schicke die EPG-Daten einfach nicht mehr mit der message mit - schliesslich sind die, wenn die message generiert wird, eh schon bekannt. Dafür muss ich in der infoviewer-Klasse (die kennt die EPG-Daten nämlich) halt eine Zugriffsfunktion machen, damit andere (namentlich remotecontrol) darauf zugreifen können. Stattdessen schicke ich die channel_id mit (wie auch schon zuvor beim EVT_NOEPG_YET-event). Die ist eigentlich nicht nötig, da die nochmals in den EPG-Infos drinsteckt, aber sonst hätte ich das Event von WithData nach !WithData verschieben müssen, ausserdem wäre es sonst theoretisch möglich, dass die falschen EPG-Daten eingeblendet werden.

Apropos falsche EPG-Daten: wenn man schnell zappte (0-0-0-0-0) und dann eine Zifferntaste drückte, konnte es sein, dass zuerst das EPG zum "Ziffern"-Kanal angezeigt wurde, dann kam für den zuletzt gezappten Kanal das current-EPG-Event und das EPG wurde überschrieben. Das habe ich auch gleich noch damit gefixt.

[rhabarber1848]

Lösung / Workaround: infoviewer-currentnext-rework.diff
Bitte testen.

Vier Minuten Extram-Zapping: keine Abstürze, keine
komischen Daten in der EPG-Anzeige in der Infobar.

[seife]

Das klingt doch mal ermutigend.
Ich jag's noch durch den valgrind, dann sehen wir, ob das taugt.

[seife]

sieht gut aus -> commited.

[-=HSKc=-Robby]

rhabarber: dann check doch das revertete erstmal ein, damit es wieder für alle geht.

Erledigt: http://cvs.tuxbox-cvs.sourceforge.net/c ... 6&r2=1.257

Ist das revertete auch wieder aus dem cvs raus?

[seife]

Klar: http://cvs.tuxbox-cvs.sourceforge.net/c ... f_format=u
Das ist jetzt ganz anders gelöst.

[-=HSKc=-Robby]

Dann werd ich Riker mal wieder nach nem Snap fragen ;-)

[GetAway]

Von mir auch positiv getestet, bzw schaffe ich es nicht mehr das es abstürzt.

Nachtrag: Vielen Dank an Euch beide!

[-=HSKc=-Robby]

Nachtrag: Vielen Dank an Euch beide!

Da kann ich mich nur anschließen!!!