Sol broken?

[tcf4004]

Hi,

kann es sein dass das Spiel Sol (nicht Solitär) nicht mehr funktioniert?

Bei Aufruf von Sol stürzt Neutrino ab und lässt sich nicht mehr bedienen.
Telnet und FTP gehen aber noch.
neutrino, sectionsd, controld & Co. werden wohl gekillt, tauchen jedenfalls
in der Prozessliste nicht mehr auf.

Im Log kommt nur das:

Code: Alles auswählen

[CPlugins] (id,val):(rcblk_rep,25)
[CPlugins] (id,val):(rcblk_anf,0)
[CPlugins] (id,val):(fd_rcinput,18)
[CPlugins] (id,val):(fd_framebuffer,3)
[CPlugins] try load shared lib : libfx2.so

Danach Lockup, auffallend ist dass noch nichtmal "[CPlugins] try exec" kommt,
wie bei den anderen Spielen/Plugins.

Der Fehler tritt reproduzierbar auf, habs mit einem newmake-Eigenbau und einem
aktuellen dietmarw-Image getestet. Im JtG-Forum habe ich gelesen dass das
wohl schon seit einigen Monaten nicht mehr funktionieren soll.

Nehme ich aus einem alten Image (wo Sol noch läuft) die sol.so heraus und
kopiere sie ins newmake-Image, dann gibt es kein Problem.
Umgekehrt, also newmake sol.so ins alte Image -> gleicher Fehler.

Die sol.cfg ist bei beiden Imageständen gleich, da kann es nicht dran liegen.
Es muss m.E. an der sol.so liegen, da wird offenbar irgendwas nicht richtig gebaut
oder irgendwas passt nicht mehr zur übrigen Architektur (obwohl ja seit
Jahren eigentlich nichts an sol verändert wurde im cvs!?).

Könnte sich das evtl. einer der Profis mal ansehen?

Danke & Gruss
tcf4004

[rhabarber1848]

Nehme ich aus einem alten Image (wo Sol noch läuft) die sol.so heraus und
kopiere sie ins newmake-Image, dann gibt es kein Problem.
Umgekehrt, also newmake sol.so ins alte Image -> gleicher Fehler.

Der sol-Code hat sich seit 4 Jahren nicht mehr geändert:
http://cvs.tuxbox-cvs.sourceforge.net/t ... s/fx2/sol/

[tcf4004]

Ist mir bewusst, das ist ja gerade das komische!

Dachte auch erst, es liegt an meiner Kompilationsumgebung...
aber der Fehler ist ja in dietwarw und JtG-Images auch vorhanden!
Normalerweise müsste das Prob ja dann irgendwo in den Sourcen sein!?

Vllt könnten das ja mal ein paar User mit ihrem Imagestand gegenchecken?

Danke & Gruss
tcf4004

[tcf4004]

So, hab das Ganze auch nochmal mit dem Yadi-Image getestet:

v2.2.0.0 vom 17.03.07 -> Sol funktioniert einwandfrei
v2.2.0.5 vom 22.03.08 -> Segfault nach Aufruf & Shutdown der Box (waiting for controld... etc.)

Also muss sich zwischen März 07 und März 08 _irgendwas_ geändert haben dass es nun nicht mehr läuft.

Nicht dass Sol überlebenswichtig wäre aber ...

[seife]

Code: Alles auswählen

seife@stoetzler:/local/seife/src/tuxbox-newmake-26/cdk> cvs diff -r 1.378 -r 1.379 rules-make
Index: rules-make
===================================================================
RCS file: /cvs/tuxbox/cdk/rules-make,v
retrieving revision 1.378
retrieving revision 1.379
diff -r1.378 -r1.379
18,20c18,20
< binutils;2.15.91.0.2;binutils-2.15.91.0.2;binutils-2.15.91.0.2.tar.bz2;extract:binutils-2.15.91.0.2.tar.bz2
< bootstrap_gcc;3.4.4;gcc-3.4.4;gcc-core-3.4.4.tar.bz2;extract:gcc-core-3.4.4.tar.bz2
< gcc;3.4.4;gcc-3.4.4;gcc-core-3.4.4.tar.bz2:gcc-g++-3.4.4.tar.bz2:gcc-core.diff;extract:gcc-core-3.4.4.tar.bz2;extract:gcc-g++-3.4.4.tar.bz2;patch:gcc-core.diff
---
> binutils;2.17.50.0.9;binutils-2.17.50.0.9;binutils-2.17.50.0.9.tar.bz2;extract:binutils-2.17.50.0.9.tar.bz2
> bootstrap_gcc;3.4.6;gcc-3.4.6;gcc-core-3.4.6.tar.bz2;extract:gcc-core-3.4.6.tar.bz2
> gcc;3.4.6;gcc-3.4.6;gcc-core-3.4.6.tar.bz2:gcc-g++-3.4.6.tar.bz2:gcc-core.diff;extract:gcc-core-3.4.6.tar.bz2;extract:gcc-g++-3.4.6.tar.bz2;patch:gcc-core.diff
22d21
<

Nur so ne Vermutung.

[tcf4004]

Ich konnte den Zeitpunkt, seit dem das Problem auftritt, noch etwas weiter eingrenzen.
Habe mal alle Yadi Images von 2.2.0.0.-2.2.0.5 durchgetestet.
Demzufolge müsste der "Fehler" zwischen Oktober 2007 und März 2008 reingekommen sein:

2.2.0.0 vom 17.03.07 -> OK
2.2.0.1 vom 07.04.07 -> OK
2.2.0.2 vom 27.05.07 -> Sol ist nicht im Image vorhanden
2.2.0.3 vom 05.08.07 -> Sol ist nicht im Image vorhanden
2.2.0.4 vom 16.10.07 -> OK
2.2.0.5 vom 22.03.08 -> Segfault/Absturz

Mit den älteren binutils/gcc Versionen bauen bin ich noch nicht zu gekommen,
aber rules-make 1.378 <> 1.379 war ja im Nov 2007, könnte also passen.
Werde das mal als nächstes ausprobieren

[tcf4004]

Ich habe jetzt nochmal mein cvs vom März mit binutils 2.15.91.0.2 und mit gcc-core/g++ 3.4.4 gebaut.
Es läuft zwar nicht ganz durch (hängt bei busybox, da hat sich irgendwas geändert), aber mit
make plugins konnte ich zumindest Sol & Co. erzeugen: startet und läuft einwandfrei

Hab dann nochmal nen Test mit neuem gcc 3.4.6 und alten binutils 2.15.91.0.2 nachgeschoben und da ging es auch,
d.h. gcc hat wohl damit nix zu tun.

Es liegt also, wie von seife schon vermutet, augenscheinlich am Releasewechsel binutils 2.15.91.0.2 -> 2.17.50.0.9 !

Jetzt stellt sich noch die Frage, was muss an dem Sol-Code geändert werden damit er auch mit
den neuen binutils 2.17.50.0.9 sauber erstellt wird...?

Evtl. ist das ja wieder so ne 64bit/POSIX/Vorzeichen/Deklarations-Nummer!?

Das Problem ist dass an dieser Stelle mein Know-How nicht mehr ausreicht um da weiter gehendes zu testen.
Aber vielleicht lesen das ja der Entwickler, Devs oder andere User und können noch einen Tipp geben.

Any ideas welcome

[tcf4004]

So, nur um das auch nochmal getestet zu haben:
gestern aktuelles cvs ausgecheckt und kompiliert
-> Problem nach wie vor vorhanden

[tcf4004]

So, ich habe nochmal ein wenig weiter geforscht:

1. Wenn man in der somain.c den Debug einschaltet, dann geht es plötzlich!

Code: Alles auswählen

Also aus

//#define SOLBOARD_DEBUG

folgendes machen:

#define SOLBOARD_DEBUG

2. Auch wenn man ein einfaches printf reinsetzt, geht es!

Code: Alles auswählen

Also an der Stelle

#ifdef SOLBOARD_DEBUG
	  printf("somain: board init\n");
#endif

einfach noch ein printf einfügen das immer abläuft:

#ifdef SOLBOARD_DEBUG
	  printf("somain: board init\n");
#endif
	  printf("somain: board init\n");

In beiden Fällen startet/läuft Sol dann einwandfrei. Ich habe mal versucht durch
printf an verschiedenen Stellen herauszufinden wo es _genau_ hängt.
Das komische ist, dass es mit printf immer ging, auch wenn bspw. der Befehl
an einer Stelle steht, die erst am Schluss abgearbeitet wird (zB bei
DrawScore):

Code: Alles auswählen

#ifdef SOLBOARD_DEBUG
		      printf("somain: before DrawScore\n");
#endif
		      DrawScore();
	  printf("drawscore ok\n");

D.h., hier ist der Init unverändert, eigentlich dürfte es m.M.n. gar nicht
gehen, da die Startsequenz ja die gleiche ist!

Ich hab den Code mal mit dem von Minesweeper verglichen, da ist die Init-
Sequenz bis auf ein paar Kommentare absolut gleich!

Ich weiss nicht mehr was ich noch testen soll, ich weiss nur dass es mit
eingeschaltetem SOLBOARD_DEBUG bzw. mit zusätzlichem printf-cmd geht,
aber _warum_ das Ganze so ist weiss ich nicht.
Ein bisschen Hilfe hier von den Pro's wäre auch nicht schlecht.

Das einzige was ich noch testen kann, ist nachzuschauen ob in den Yadi-
Versionen wo es geht, der Debug auch an ist (und ob es evtl. deswegen
dort geht). Sollte das der Fall sein, wurde wohl im cvs (somain.c) der Debug
inaktiv gesetzt, die Versionsnummer wurde jedoch anscheinend nicht geändert.

Gruss
tcf4004

[dietmarw]

das ist wieder eins der "nicht-mit-dem-kernel-update-zusammenhängenden-aber-doch-dadurch-beeinflussten" probleme..

[seife]

Nein, das hat mit dem Kernel vermutlich nichts zu tun, dafür mit den binutils.

[dietmarw]

hmm.. an irgendeiner stelle ein printf einfügen um den fehler zu umschiffen
hört sich aber nach einem seeehr ähnlichen problem an..

[tcf4004]

so, hab noch was getestet, hier mein Fazit:

1. Problem tritt offenbar seit Wechsel auf binutils 2.17.50.0.9 auf
2. Ein printf("irgendwas\n"); _irgendwo_ in der somain.c und Sol startet einwandfrei
3. // vor #define SOLBOARD_DEBUG in somain.c wegmachen (=Debugausgaben), dann gehts auch ohne Probleme

Ich habe das printf mal ganz am Ende nach FBClose(); eingefügt, dort _kann_ es beim Start gar nix bewirken,
da dieser Part erst ganz am Ende abgearbeitet wird. Trotzdem geht Sol dann einwandfrei! Verrückt, aber Fakt.
Und mit Debug geht es wohl deswegen weil dort ja dann auch printf's aufgerufen werden.

Die älteren Yadi-Images wo Sol noch ging haben jedenfalls keine Debug-Ausgaben, d.h. die wurden definitiv
ohne printf o.ä. richtig gebaut (mit alten binutils). Woran das aber nun liegt vermag ich nicht weiter
herauszufinden, da mein know how an dieser Stelle ausgeschöpft ist.

ok, jetzt stellt sich nur noch die Frage welcher von beiden Würgarounds soll eingecheckt werden

Danke & Gruss
tcf4004

[rhabarber1848]

Teste mal binutils-2.19.51.0.4, vielleicht ist der Fehler dort behoben:
http://forum.tuxbox-cvs.sourceforge.net ... =7&t=48686

[rhabarber1848]

3. // vor #define SOLBOARD_DEBUG in somain.c wegmachen (=Debugausgaben), dann gehts auch ohne Probleme

committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1995