+- Deutsches Simutransforum (https://simutrans-forum.de/mybb)
+-- Forum: Simutrans (https://simutrans-forum.de/mybb/forumdisplay.php?fid=3)
+--- Forum: Archiv (Abgeschlossene Arbeiten) (https://simutrans-forum.de/mybb/forumdisplay.php?fid=15)
+--- Thema: Leck in Ablaufroutinen? (/showthread.php?tid=736)
Leck in Ablaufroutinen? - Uranor - 14-08-2005
Simutrans-Version: 86.07
PAK-Set (+zusätzliche PAK-Dateien): pak.german und pak128
Betriebssystem: WIN XP
Fehler (möglichst genaue Beschreibung): Dtails unter "Verhalten", s. dort.
Verhalten (Absturz, Einfrieren, ...):
pak128, Spielstart, Spielstand laden: 1 Spielstand wird doppelt mit verschiedenen Uhrzeiten angezeigt. Herkunft unbekannt, Spielstand wurde tatsächlich vor kurzem überschrieben. Fehler reproduzierbar, tritt bei späterem Spielstand laden nicht mehr auf.
pak.german, Aufruf eines Sehenswürdigkeitendiaolgs: Spontaner Spielabsturz, soweit erkennbar saubere Speicherfreigabe. Objekt war leider nicht mehr feststellbar, bei anderen vergleichbaren Aufrufen zeigten sich keine Auffälligkeiten.
pak.german, Spiel beenden über Dialog-Item "Beenden": Screen wird schwarz, Vorgang friert ein, wird wieder aufgenommen nach Wechsel mit ALT+TAB zu einer anderen Anwendung. Soweit erkennbar, nun sauberes beenden.
pak128 (pak möglicherweise unerheblich), Pausemodus, dann wechseln mittels ALT+TAB zum Desktop, nach Wiederaktivierung des Spiels durch Mausbewegung benötigten Sichtbereich refresht, Spiel mit "Beenden"-Dialog beendet: Anwendung räumt sich nicht sauber ab. Dateimanager Idoswin free zeigt auch nach Verzeichniswechsel keine Verzeichnisinhalte mehr an. Der ebenfals geöffnete IE ließ sich problemlos bedienen, minimieren, maximieren, kein Anzeichen auf ein allgemeines Speicherleck mit Speicherverbrauch. Systemneustart war angezeigt.
Vager Eindruck: Möglicherweise fehlen noch delete-Routinen.
- prissi - 14-08-2005
So ungefähr seit DOS 2.11 sollte das Betriebsystem allen resevervierten Speicher beim Beenden auch wieder freigeben, ohne dass explizit eine Routine dazu aufgerufen wurde. Speziell bei Speicher, der über "malloc" alloziert wurde, sollte das zusätzlich auch die Laufzeitbibliothek übernehmen.
Das Verhalten, was du schilderst, liegt eher daran, dass Windows wichtige Strukturen überschrieben wurden. Allerdings sollte XP dass nicht mehr zulassen.
- Uranor - 15-08-2005
Hmmm, das Problem meldete sich allerdings spontan bei der neuen Version und tritt nur im Zusammenhang mit ihr auf. Kann sich das Problem ggf. lokalisieren lassen? Ansonsten sollte ich wohl besser wieder auf die Vorversion zurückgehen. Bin natürlich ratlos. Meine interne Systemkenntnis ist praktisch NULL.
NachPS: *Uff*, hab es probiert, Spielstände sind nicht abwärtskompatibel. Beim Ladeversuch mit 86.06 verabschiedet sich das Spiel spontan, glatt, sauber und Rückstandsfrei. 8) ... Nein, natürlich gar nicht 8) . Etwas an der neuen Version scheint ungenießbar zu sein.
Zeigt sich auch bei anderen solches Verhalten, wie ich es schildern musste? Kann ja sein, dass meine olle Wackelkiste ganz einfach auf den Schrott gehört. ;( , denn ansich kann ich ihr nur Stabilität und prima Funktion nachsagen.
- prissi - 15-08-2005
Es gibt ein kleines Memoryleck bei der Routensuche. Nachdem allerdings ein Spiel mit ca. 2 Millionen Passagieren pro Jahr anstandslos zehn Jahre lief, ist das vermutlich nicht der Fehler.
Das mit Beenden liegt vermutlich daran, dass in deienem Spiel viele Objekte dort waren, wo sie nicht hingehören. Dann such Simutrans die ganze Karte nach dem Objekt um es auch an der anderen Position zu löschen und keine Leiche zu hinterlassen. Das spräche dann für interne Speicherzugriffsfehler.
- Uranor - 15-08-2005
Ahhh, sowas ist denkbar, @prissi. Es bestand auch ein (natürlich sehr subjektiver) Eindruck, das Spiel wolle etwas tun, benötigt dafür aber furchtbar viel Zeit und schaffte es im Endeffekt nicht. Ich hatte vor weiteren Maßnahmen also gewartet, dann aber aufgegeben. - Intuition am PC. ich mach das nicht bewusst. Doch ich muss nur ganz selten Hilfe suchen. Wirst den Effekt des Powerusers + volles Hintergrundwissen sicher auch kennen. Blinde Masse ohne Gefühl kann niemals klasse sein. =)
Momentan registrier ich das Prob nicht. "Objekte, die da nicht hingehören"... Die Vorversion und die neue sind da möglicherweise verschiedener Ansicht. Die neue kann (bedingt) reparieren, die alte kapituliert. Bei "oh ja" sollte der Fehler als eingekreist gelten.
Tendentiell kann aber ein Prob mit Karten überhaupt bestehen. Nicht nur Ladeversuche mit Reliefkarten machen Probs incl. Absturz. Mir ist es auch schon 2 mal beim Generieren einer 64-er Testkarte (im pak128) passiert. Vielleicht harmonieren die Generierung und die Erwartungen im laufenden Spiel nicht in allen Fällen?
Z.B. gehörte der spielbare Kartenrand jemandem. Ein Absenkversuch der Randkachel erbrachte eine Meldung bzw. sehr hohes Absturzrisiko.
- millo - 16-08-2005
Zitat:Original von prissiDu willst jetzt aber nicht sagen, daß Du Dich darauf verläßt. Das wäre ganz ganz schlechter Programmierstil ... und würde meinen Glauben in Dich und Deine Programmierkunst arg erschüttern.
So ungefähr seit DOS 2.11 sollte das Betriebsystem allen resevervierten Speicher beim Beenden auch wieder freigeben, ohne dass explizit eine Routine dazu aufgerufen wurde. Speziell bei Speicher, der über "malloc" alloziert wurde, sollte das zusätzlich auch die Laufzeitbibliothek übernehmen.
Grüße aus dem Erzgebirge, millo
- prissi - 16-08-2005
Es gibt eine Routine, die Speicher für Blöcke bis 64 Bytes effektiv verwaltet. Die hat wesentlich weniger Lecks als die Alte, nämlich keine mehr. Allerdings gibt sie die Blöcke beim Beenden des Programmes nicht explizit zurück. Die Änderung wäre einfach, nur hatte eine gut funktionierende Version bei mir erste Priorität.
Du bist übrigens gerne eingeladen, den code durchzusehen. Ich bin ziemlich sicher, es gibt ein Leck im Leitungskode beim verbinden zweier Leitungen. Alle Versuche, es zu beseitigen führten aber zu Abstürzen.
Was soll man da machen? Zumal Simutrans wegen der SDL nicht unter Windows debugbar ist (da SDL der main-thread ist) und mein Linux nach der x-ten Neuinstallation immer noch nach ca. 5-30 Minuten vermutlich wegen einem "spurious Interrupt" komplett einfriert.
Mit "printf" konnte ich den Fehler jedenfalls nicht weiter einkreisen. valgrind gibt korrekte Statements als Fehler aus. Was soll ich da machen? (Und ich habe wirklich Erfahrung mit printf-Debugging von Mikrocontrollern und PalmOS aus der Frühzeit.)
Malloc reicht die Blöcke eh durch und gibt am Ende alles frei, das hat keine hohe Priorität. Wichtiger war mir, dass im Spiel nichts verloren geht bzw. ordentlich freigegeben wird.
- Uranor - 16-08-2005
"Wichtiger war mir, dass im Spiel nichts verloren geht bzw. ordentlich freigegeben wird.". @prissi, das meinte ich mit delete, vielleicht war in einer Destructor-Routine was übersehen. Nach deiner Darstellung wunder ich mich allerdings nicht mehr, wieso ich praktisch nur vage ins Geschehen hinein blicken kann. Etwa von SDL hab ich ja nicht die geringste Ahnung. Ich werd glücklich sein, wenn ich wenigstens mal einen Dialogaufbau bzw. Ereignisroutinen erkennen kann. Dazu kommt natürlich die Größe, ohne Rahmenalgor und Konzepte zu kennen. - Es wird dennoch nützen können. Es braucht nur Zeit.
Linux-Distributionen kannte ich allerdings vor Jahren als stabil, ich sag nur Halloween 7. Mit anderen war ich allerdings defakto nicht glücklich.