Obfuscate, Grund vieler sporadischer Abstürze ?

Ich wollt hier mal 2 Phänomene einwerfen, die mich nun nahezu sicher zu der Überzeugung bringen, daß die ganze Obufscaterei nur für eins "gut" ist : Probleme zu bereiten und für Abstürze zu sorgen. Phänome Nummer 1, durch Zufall in einer Cartridge eines Kollegen entdeckt. Er hat in einer Messagebox einen Text in eckigen Klammern stehen. MIT (!) der Checkbox "Obfuscate Strings" lässt sich es sich starten, nicht jedoch ohne. Dabei gilt noch, daß die eckigen Klammern in einer neuen Zeile stehen, nicht in der aktuellen, denn hier funktioniert alles. Lässt sich 100% nachvollziehen :
1.Zeile : Hallo [Blabla] > funktioniert mit und ohne Obfuscate
aber
1.Zeile : Hallo
2.Zeile : [Blabla] > funktioniert NUR MIT (!) Obfuscate

Nicht weiter dramatisch, denn man sollte eh nie eckige Klammern einsetzen. Also raus mit dem Schmodder. Achja, die Fehlermeldung die Urwigo dann schmeißt, sieht so aus :



Das 2. Phänomen ist schon sehr viel pikanter und imho der Grund sporadischer und v.a nicht nachvollziehbarer Fehler. Wir hatten das hier schon mal in der Form, daß am Anfang eines Textes, egal ob es statischer Text oder eine Variable ist "GetCorrect" oder "GetCorrectStatibleTasks". Bei fantastrialliarden Testläufen, in denen ich beim Komplilieren das Obfuscate deaktiviert hatte, gab es NIE diesen Fehler. Dann nahm ich es mal wieder rein und schon beim 4. oder 5. mal trat dieser Fehler auf (links, wie es sein soll, rechts die resultierende Anzeige) :



Jaja, mein Displayschutz müsst ich mal wieder tauschen
Auf jeden Fall äußert sich der Fehler hier "nur" in einem verstümmelten Text, aber ich bin der Überzeugung daß dies genauso verkryptete Objektnamen betrifft (Checkbox "Obfuscate Identifiers") und dann sind die Auswirkungen klar : Es wird versucht auf ein Objekt zuzugreifen, daß einen falschen/keinen Namen hat. Das sind dann die Logeinträge, in denen was von "nil value" steht. Vielleicht nicht alle, aber einige davon resultieren imho aus diesem Fehler.

Also zusammenfassend : Was ist überflüssiger als Zecken ? Genau, die Obfuscate Funktion. Was ist noch überflüssiger als Obfuscate und Zecken zusammen ? Könnt ein D1 Mystery sein mit vorgegebener Antwort im Listing : Simulatorschutz

1. Die Frage ist ja, wie die Zeichenkette in der Cartridge definiert ist. Über mehrere Zeilen kann man ja eigentlich nur mit [[ und ]] gehen. Wird der String mit "" eingefasst, dann gibt es keinen Zeilenumbruch. Wird nun die Zeile mit Obfuscation verschlüsselt, wird jedes Zeichen durch den Steuercode ersetzt. Eventuelle auch der Zeilenumbrauch (alles hier ist nur Spekulation). Damit funktioniert das Ganze mit Obfuscation, aber nicht ohne.

2. Den zweiten Fall habe ich noch nicht ganz kapiert. Diese Funktionen GetCorrect und GetCorrectStatibleTasks: sind das Funktionen von Urwigo oder der Cartridge? Kannst Du den Quellcode bereitstellen, wenn das Problem auftritt oder tritt das Ganze nur "on-the-fly" auf?

Punkt 1 muss man eigentlich auch nicht näher untersuchen, eckige Klammern halt niemals benutzen.

Punkt 2 ist dagegen sehr mysteriös, irgendwas mit "Get" gibts in den Lua Sourcen die im GWZ stecken gar nicht. Da könnte auf dem Button auch "Print starten" stehen, keiner weiß wos herkommt, aber nach den bisherigen Erkenntnissen eben NUR wenn die Obfuscaterei aktiviert ist. Deswegen auch die Vermutung, daß es sich nicht nur bei der Stringmasquerade auswirkt, sondern auch bei den Objekten/Identifiern und das wäre natürlich verheerend und würde vielleicht einige nicht nachvollziehbare Crashs erklären.

Ich hab den Beitrag gefunden wo das schon mal angesprochen wurde : http://forum.geoclub.de/viewtopic.php?f=74&t=65112&start=20#p1028070

Ich nehme an, dass es sich dabei um Probleme mit string:byte und string.char handelt. Die angezeigten Zeichenkette "GetCorrectStateibleTasks" setzt sich aus dem Attribut "CorrectState" und der Funktion "GetActiveVisibleTasks" zusammen. Deshalb denke ich, dass die Obfuscation-Funktion in falschen Speicherbereichen wildert. Warum der Fehler nicht immer auftritt? Wenn ich es richtig verstanden habe (habe nur 2 verschiedene Urwigo-Dateien angeschaut), wird die Zeichenkette, die zur Verschlüsselung dient, immer wieder bei jedem compilieren neu erzeugt. Eventuell ist sie bei jedem 4. oder 5. mal gleich. Aber es dürfte tatsächlich sehr schwer sein, den Sachverhalt nachzuprüfen, da es beim nächsten Compiulervorgang oder beim Erzeugen der GWZ Datei ja schon wieder anders ist

Die Verschlüsselung der Funktionen und der Objekte ist eine statische Sache und ob ein Objekt "zitemTest" oder "hFtrELh_j" heißt, sollte eigentlich egal sein. Da erwarte ich eigentlich keine Probleme. Nur sehr viel schwerer lesbar ist der Code

Charlenni schrieb:

Die Verschlüsselung der Funktionen und der Objekte ist eine statische Sache und ob ein Objekt "zitemTest" oder "hFtrELh_j" heißt, sollte eigentlich egal sein. Da erwarte ich eigentlich keine Probleme. Nur sehr viel schwerer lesbar ist der Code

Zum Vergrößern anklicken....

Na, da bin ich mir aber sehr unsicher, ob das wirklich egal ist nach solchen Vorkommnissen wie im Messagetext und sogar auf dem Button. Bekräftigt wird meine Vermutung auch dadurch, daß ich bei Testläufen eine ausgesprochen hohe, viele höhere Stabiliät hatte, als mit dem Verschlüsselungsgedöns. Oder sagen wir mal andersrum : Obfuscate trägt NICHT zur Stabilität bei, alles andere sie mal dahingestellt. Beweise hab ich ja auch nicht, nur Vermutungen.
Aber Messages wie "Hallo GetCorrectkommen in Zone 1" sind so oder so kacke.