mike1304 schrieb:

@worf66:
Wenn es wirklich der Crash mit

Brainfuck-Quellcode

1. 14:15:10.705 [e2-core] [bsod.cpp] --------------------------------
2. 14:15:10.705 [e2-core] DebugInfo:
3. 14:15:10.705 [e2-core] /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x79C1C]
4. 14:15:10.706 [e2-core] /lib/libc.so.6(__default_rt_sa_restorer) [0xB620B6C0]
5. 14:15:10.706 [e2-core] [bsod.cpp] --------------------------------

ist, dann nimm doch das Angebot aus Post #214 an und schick Dein Image zum Testen an GaborDenes

Dieser Fehler lag am Skin. Habe jetzt Metrix HD drauf und damit geht es nicht mehr mit 3x EPG drücken. MuteSpectator (HD) war es vorher

Ich hatte das GUI neustart Problem an meiner Ultimo 4k ca. 3-5 mal am Tag, habe jetzt vor ca. 4 Tagen meine Box kommplett neu geflasht und alle Plugins usw. neu installiert.

Ausser meine Kanalliste die ich mit Dream box Edit wieder übertragen habe, habe ich keine Einzige Einstellung oder Plugins wiederhergestellt, alle Einstellungen usw. wurden neu erstellt.

Ich hatte seit dem keinen einzigen GUI neustart bzw. reboot mehr.

(Fluid Next, Media Portal, Cool TV, VMC, Easy Media , FCC permanent ein, Alexa Plugin) sind so im großen und ganzen die Plugins die am laufen sind, wie gesagt seit 4 Tagen kein einziges Problem mehr, ich hoffe es bleibt wie es ist.

Das sagt noch nichts.

nochmal EPG:
bei mir ist nach Gui-reboot epg leer.
bei euch auch?
vg.

Nachtrag: gestern mit Kollege Neujahrsbier getrunken.
-nach 15 min: Dauerspinner.
-nach 1 h: plötzlicher gui-reboot ohne jede aktion an Fb
-dann 3 h normal.

Wo wird bei dir epg.dat gespeichert?

@ronaldse
das hab ich auch schon alles hinter mir, dachte mit original Image und ohne Plugin ist alles gut .... leider nicht.

@plnick klar könnte man warten, aber wie lange? ich will die Box ja nutzen und wieder wie schon mal gehabt wieder eine Funktionierende Box. Würde die ungern zurück senden.

ich hab derweil noch mal einige Logs, wenn gewünscht kann ich die Uploaden. Hier fällt mir immer auf dass libc.so.6 drin vor kommt, hier ein Beispiel.

@sattim1

Letzter GUI-Reboot am 28.12.
Danach hab ich als Einziges die Bouquet-Einstellungen von nein auf ja gestellt s. Anhang
Seitdem keine Probleme. Wirds wahrscheinlich nicht gewesen, aber was solls

steht bei mir auf Ja, Nein, Nein
Werde es mal auf Ja Ja Ja wie bei dir umstellen

sattim1 schrieb:

@ronaldse
das hab ich auch schon alles hinter mir, dachte mit original Image und ohne Plugin ist alles gut .... leider nicht.

@plnick klar könnte man warten, aber wie lange? ich will die Box ja nutzen und wieder wie schon mal gehabt wieder eine Funktionierende Box. Würde die ungern zurück senden.

ich hab derweil noch mal einige Logs, wenn gewünscht kann ich die Uploaden. Hier fällt mir immer auf dass libc.so.6 drin vor kommt, hier ein Beispiel.

[bsod.cpp] --------------------------------
DebugInfo:
/usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x79C1C]
/lib/libc.so.6(__default_rt_sa_restorer) [0xB61E46C0]
/usr/bin/enigma2(_ZN9eMainloop15processOneEventEjPP7_object9ePyObject) [0x81CD8]
/usr/bin/enigma2(_ZN9eMainloop7iterateEjPP7_object9ePyObject) [0x820FC]
/usr/bin/enigma2(_ZN9eMainloop4pollE9ePyObjectS0_) [0x82258]
/usr/bin/enigma2(n/a) [0x1BB7A4]
[bsod.cpp] --------------------------------
]]>

Ich habe OpenATV und das Originalimage bereits mehrere Wochen ohne Abstürze getestet, somit kann ich in meinem Fall die Hardware ausschließen (Und bei den meisten Logposts hier ebenfalls, sonst würde Enigma2 komplett abschmieren und nicht nur ein GUI restart generiert werden). Und ich habe jedes Mal das Image neu aufgesetzt ohne Plugin-Installationen. Und es treten immer die selben Fehler auf. Das Log ist entweder leer oder nach __default_rt_sa_restorer kommt nix mehr, auch bei der neuesten Version. Einzig verdächtig ist der Zusammenhang mit dem EPG refresh oder dem Tunerlock ... ich denke da wird der Hund begraben sein.

Mal zum allgemeinen Verständnis ... da ich nicht zum ersten Mal Bugs bei enigma2-Boxen fixe :

/usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x79C1C]
/lib/libc.so.6(__default_rt_sa_restorer) [0xB61E46C0]

/lib/libc.so.6 ist die Library für die C Runtime, ohne die gar nix läuft (auf keiner ARM-Platform). Das Problem ist hier nicht zu suchen, das muss so sein. __default_sa_restorer ist ein Signalhandler, d.h. bei einem Interrupt wird ein Signal generiert, in diesem Fall die Tatsache, dass Code abgestürzt ist. Dieses Fehlersignal wird dann auch an Enigma2 weitergeleitet in Form von _Z17handleFatalSignaliP9siginfo_tPv. Auch das ist nicht das Problem.

Interessant sind wenn denn dann die Zeilen unter dem _default_rt_sa_restorer, also in deinem Beispiel :

/usr/bin/enigma2(_ZN9eMainloop15processOneEventEjPP7_object9ePyObject) [0x81CD8]
/usr/bin/enigma2(_ZN9eMainloop7iterateEjPP7_object9ePyObject) [0x820FC]
/usr/bin/enigma2(_ZN9eMainloop4pollE9ePyObjectS0_) [0x82258]

Da hier auf ein PyObject, also ein Python object referenziert wird beim Pollen der eMainloop, ist der Fehler eher in einem Pythonscript zu suchen (und das liegt dann am Image und nicht an der Hardware oder den Treibern Hier würde ein Blick auf die Debugloop helfen zu sehen, welches Plugin/Script zuletzt ausgeführt wurde.

Mein Problem (und das bei denen der Reciever ohne zutun sporadisch abschmiert per GUI-Absturz) ist aber, dass ich nach __default_rt_sa_restorer kein weiteres Log habe und auch das Höhersetzen des Debuglogs nichts anzeigt. Da das VTI nicht quelloffen ist, kann ich leider auch nicht beim Bugfixen helfen, weil ich nicht weiss, wie ich VTI debuggen könnte. Hats mal jemand probiert, den enigma2 per GDB zu debuggen z.B. remote ? (Main Developer von VTI angugg) ?

Ich würde auch gern VTI einsetzten, weils mehr mehr zusagt, aber die Abstürze nerven halt

GDB gibt es nicht auf der Box. Das muss man sich erst bauen. Dasselbe gilt für valgrind.

@plnick
Wenn du schreibst dass alle Images betroffen sind, dann mag das sein, aber dann ist es vermutlich nicht der Bug den ich hab, sondern ein anderer Bug. Der von mir beschriebene Bug tritt bei mir nur beim VTI Image sporadisch auf (und ja, ich bin mir da absolut sicher).

Kannst du bitte mehr Details geben, was derzeit gefixt wird (VTI scripts oder Enigma2 oder Box Treiber) ?
Ich stell mich auch gern als Tester inkl. GDB Session zur Verfügung.

hallo maerd
die Umstellung hat nichts bewirkt. Nach ner Stunde ist die Lady wieder da gewesen.

müssen dann wohl warten bis plinck da was für uns hat, scheint ja so dass hier schon welsche dran arbeiten.
Aber als Blödsinn und als Chaos dass hier die Leute sich gegenseitig helfen wollen würde ich den ganzen Thread nicht bezeichnen.

ca. 5% der Beiträge wollen helfen

Hallo sattim 1,
tut mir leid, hab mir schon gedacht, dass es nicht daran liegt.
Ist bei mir wohl Zufall

Also ich helfe weiterhin gerne (im Rahmen meiner User-Möglichkeiten) ...

Habt Ihr eigentlich auch alle die Übermittlung des Chrashlogs aktiviert? Die Häufigkeit nimmt hier subjektiv gefühlt zu, aber das wird daran liegen, dass ich das Teil jetzt aus Protest dauerhaft vor sich hin rödeln lasse. Aber dafür werden die Crashlogs jetzt auch öfters mal detailierter, wie das hier ...

Einer meiner Crashes deckt sich mit diesem OpenATV-Bugfix:
[frontend.cpp] Fix crash at heavy AutoTimer/EPGrefresh load · openatv/enigma2@af03b03 · GitHub.

Das ist im VU repository nicht gefixt. Und das würde auch erklären, warum OpenATV bei mir stabil läuft.

eDebugNoSimulate("dont close frontend %d until the linked frontend %d in slot %d is still in use",
598 m_dvbid, linked_fe->m_frontend->getDVBID(), linked_fe->m_frontend->getSlotID());

599 return -1;

Sollte eigentlich so aussehen :

eDebugNoSimulate("dont close frontend %d until the linked frontend %d in slot %d is still in use",
598 m_dvbid, linked_fe->m_frontend->getDVBID(), linked_fe->m_frontend->getSlotID());
599 if(!m_simulate) m_sn->stop();
600 m_state = stateIdle;
601 return -1;

Noch viel schlimmer isses aber, wenn man zwei FBC im Einsatz hat, weils dann n Buffer Overflow gibt, das ist im VU repo auch noch nicht gefixt (bei OpenATV und Enigma2 Base aber schon) :
git.opendreambox.org Git - enigma2.git/blobdiff - usr/include/enigma2/lib/dvb/sec.h

Das ist aber bei mir nicht der Fall, weil ich nur einen FBC drinnen hab.

Ich warte jetzt mal was plnick fixt. Sollte der Crash dann noch bestehen, leg ich selbst Hand an, weil der erste Bug bei mir auftritt

danke für alle Bemühungen allseits.

"Noch viel schlimmer isses aber, wenn man zwei FBC im Einsatz hat, weils dann n Buffer Overflow gibt"
ich hab dad und nich nen Dritten.

konnte ev. zum Teil erklären, warum einige mehr crashes haben.

thusl schrieb:

wenn man zwei FBC im Einsatz hat, weils dann n Buffer Overflow gibt

Wie soll sich das denn äussern?
Ich habe zwei FBC SAT Dual und einen DVB-C/T2 Dual Tuner verbaut und keine Probleme?

Der Bug wird getriggert wenn du mehr als 4 Satelliten konfiguriert hast (Oder 4 unterschiedliche Configs mit zwei FBC Tunern). Der Overflow bewirkt undefiniertes Verhalten, sprich es kann alles ok sein, aber dann irgendwann irgendwo crasht die Box und man kann nicht nachvollziehen wieso (Im Wesentlichen ein Stack Problem). Ich denke nicht dass der Bug verantwortlich ist für die spontanen Abstürze bei normalen Configs.