Schlimmer Fehler - Programm friert sporadisch nach gewisser Zeit ein - Timer in While-Schleife

Aus eigener Erfahrung kann ich dir sagen, dass die Fenster schnell einfrieren, wenn sie sehr oft angesteuert werden. Zum Beispiel, wenn du ein Label via ControlSetText in jedem Schleifen-Durchgang setzen lässt. Ich könnte mir vorstellen, dass du hier das selbe Problem hast:

If IniRead(@ScriptDir & "\CODE\TMPDATA\STATES\userdata.cw1", $readlogin1, "ActiveProfile", "") = "---" Then
			WinSetTitle($main_form, "", $Titlename & " | Benutzer: " & $readshowname & " | Schulungsprofil: ---")
		Else
			WinSetTitle($main_form, "", $Titlename & " | Benutzer: " & $readshowname & " | " & _
					"Schulungsprofil: " & $READPROFILE & " (" & IniRead(@ScriptDir & "\DATA\USERS\" & $readlogin1 & "\PROFILES\" & $READPROFILE, "GlobalInfo", "Date", "") & "-" & _
					IniRead(@ScriptDir & "\DATA\USERS\" & $readlogin1 & "\PROFILES\" & $READPROFILE, "GlobalInfo", "DateEnd", "") & ")")
		EndIf

In diesem Teil deiner Schleife versuchst du den Titel des Fensters zu ändern - und das jede Sekunde. Und vollkommen unabhängig davon, ob sich der Titel eigentlich ändern würde oder nicht.

Zitat von KriZza

Ich habe nun die vermutung

was dir NICHTS bringt, genauso wenig wie das rumgestochere im Nebel!
Wieso benutzt du nicht die in Scite vorhandenen Debugging-Möglichkeiten wie bspw. DebugTrace oder Tracelines, um den "Fehler" erstmal zu lokalisieren?!

genau so macht man das...
Wenn dein Script jetzt einfriert, dann steht in der letzten Zeile der Console der zuletzt umgesetzte Befehl. Genausogut kann es sein, dass du in einer Schleife gefangen bist und nicht wieder herauskommst.
Alles in allem musst du wissen, in welchem Codesegment der "Fehler" auftritt, um ihn näher einzugrenzen.
Im nächsten Schritt lässt du dir nur im kritischen Segment die Meldungen ausgeben, ergänzt ggf. durch Variableninhalte.
Schau dir dazu im Menü auch DebugtoConsole an, damit ( Cursor auf die Variable und dann ALT+d ) bekommst du Infos in der Console zum Variableninhalt.

Wenn du den Speicher vollknallst, hast du wohl irgendwo ein memleak produziert. Prüfe am besten Mal, ob du jeden Speicher, den du anforderst auch wieder freigibst.

Übliche Kandidaten hierfür sind IniWrites, IniReads, FileWrites, FileReads, ... wenn dein Programm länger läuft, sollte all dies über Handles geschehen, da der Speicher sonst nicht freigegeben wird. Dies kann schnell zu einem memleak führen:

Nehmen wir an, du hast eine Ini-Datei. Diese Ini-Datei ist - der Einfachheit halber 1MB groß. Jetzt stößt du einmal pro Sekunde 5 IniWrites an und gehst dabei über den FileNamen.

Das bedeutet, dass AutoIt die Ini-Datei 5x pro Sekunde in den Speicher läd - kurz 5 MB/s. Ausgehend von - wieder der Einfachheit halber - 5 GB Arbeitsspeicher bedeutet dies, dass dein Speicher in 1000 Sekunden (also etwa 15 Minuten) aufgebraucht wäre, und es nicht möglich wäre, weiteren Speicher zu beziehen.

hmm, imho müsste dein Script schon ziemlich lange laufen, wenn die Scite-console den Speicher vollaufen lässt...

Nimm die Trace-lines raus, und setze "von Hand" per ALT+d in jede der IF-Verzweigungen eine Abfrage.

Hat die Konsole nicht einen Überlaufschutz ?
Dachte die Arbeitet ab einere gewissen Größe nach dem First in First out Prinzip. (Habe es aber jetzt nicht getestet, dafür müsste ich ja Stundenlang die Konsole vollschreiben lassen :D)

- Zum Arbeitsspeicher: AutoIt kann maximal 4GB (früher mal 2) adressieren. Dein Error tritt auf, sobald diese erreicht sind.
- Ini-Funktionen haben ein eingebautes FileOpen und FileClose, genauso wie die FileRead Funktionen. Wenn man überall ohne Handles arbeitet läuft da nichts über. (Jedenfalls meine Erfahrung dazu)
- Wenn das Skript so viel Speicher braucht wird an irgendeiner Stelle RAM reserviert und nicht wieder freigegeben.
- Falls du Maps und Arrays kombiniert nutzt wirst du das ändern müssen, da hier ein Memoryleak in AutoIt vorliegt.
- Handles die nicht freigegeben werden verbrauchen etwas Speicher.
- Extrem große Arrays (vllt zu Anfang klein und durch ArrayAdd über lange zeit sehr groß).

Hier kannst du mal ausprobieren wie voll du das RAM bekommst bis der Fehler auftritt. Benutzt wird ein Großes Array mit String einträgen. Bei mir sind die 4GB in einigen Sekunden erreicht und das Skript stürtz ab. Benutzung auf eigene Gefahr, je nach Windowseinstellungen und vorhandenem RAM versucht er Daten auf die Festplatte auszulagern, was ohne SSD ekelhaft werden kann. Das soll nur ein Beispiel sein, wenn der String länger (und nicht immer gleich ist) verbraucht AutoIt wesentlich mehr RAM, so kann man die 4GB auch mit wesentlich kürzeren Arrays erreichen.

#include <WinAPIProc.au3>


HotKeySet('{ESC}', 'X')


Global $iTimer = TimerInit(), $aArray[2^24], $i = 0, $r


While True
	For $o = 0 To 2^10 Step 1 ; in 1024er Schritten
		$aArray[$i+$o] = 'Hier könnte Ihr Text stehen. Oder auch nicht, denn dieser Text ist nicht Ihr Text, sofern dieser Text nicht Ihr Text ist.' & _
		'Hier könnte Ihr Text stehen. Oder auch nicht, denn dieser Text ist nicht Ihr Text, sofern dieser Text nicht Ihr Text ist.' & _
		'Hier könnte Ihr Text stehen. Oder auch nicht, denn dieser Text ist nicht Ihr Text, sofern dieser Text nicht Ihr Text ist.'
	Next
	$i += 2^10
	If $i + 2^10 >= UBound($aArray) Then Exit
	If TimerDiff($iTimer) > 250 Then
		$r = _WinAPI_GetProcessMemoryInfo(@AutoItPID)[9]
		ToolTip('Index: ' & Format($i, True) & @CRLF & 'RAM: ' & Format($r) & @CRLF & 'RAM/Index: ' & Format($r/$i))
		$iTimer = TimerInit()
	EndIf
WEnd


Func Format($i, $b = False)
	Return $b ? $i > 10^6 ? (Round($i/10^6, 2) & 'M') : $i > 10^3 ? (Round($i/10^3, 2) & 'K') : Round($i, 0) : $i > 2^20 ? (Round($i/2^20, 2) & 'MB') : $i > 2^10 ? (Round($i/2^10, 2) & 'KB') : (Round($i, 0) & 'B')
EndFunc


Func X()
	Exit
EndFunc

lg
M

Im Startpost steht ausschliesslich etwas übers "einfrieren" des Scripts, der Speicherüberlauf tritt doch nur bei Anwendung der Trace/Debuglines auf?!

"Einfrieren" heißt, dass die GUI keine Eingaben mehr entgegen nimmt, oder dass keine erwarteten Programmaktivitäten beobachtbar sind.
Ursachen dafür sind meist eine Endlosschleife oder eine vom Programm erwartete Userinteraktion.
Wenn ich im Startpost sehe, dass sogar externe Programme involviert sind, vervielfacht sich das Problem!

Zitat von KriZza

Nur mal kurz eine Kennzahl, im Hauptscript sind 1246 IniRead´s hinterlegt.. Das wird auf jeden Fall dauern

Du sollst nicht jedes einzelne IniRead() dokumentieren, sondern das Problem im Code lokalisieren!
Beim "Einfrieren" des Programms muss in der letzten Zeile der Console der Weg zum nächsten Schritt stehen...
Und diesen nächsten Schritt musst du dann wieder eingrenzen! Und logischerweise ALLE ÜBERFLÜSSIGEN Debug-Lines rausschmeissen!
Bis du zuletzt den Logikfehler oder Laufzeitfehler gefunden hast...

Zitat von KriZza

meint ihr ein "_FTP_ProgressUpload" / "_FTP_ProgressDownload" gehört auch dazu?

kommt darauf an ob du die Handles von _FTP_Open und _FTP_Connect nur einmal erzeugst und wieder verwendest, oder ob du sie jedes Mal neu erstellst und die alten nicht mit _FTP_Close schliesst.

Mars: Meine Erfahrung hierzu: Wenn man nicht mit Handles arbeitet wird der Speicher nicht wieder frei gegeben. Das Problem hatte ich mal bei einem Dienst den ich zuerst via svrany laufen hatte und anschließend mit AlwaysUp. Letzteres schickte mir pro Tag 19 Mails dass das Programm über 150MB Arbeitsspeicher reserviert hatte. Und das, obwohl ich keine Maps verwendet habe nur einen Array zu dem keine Daten hinzugefügt werden und sonst fast ausschließlich Dateibefehle. Ansonsten nur noch einen Ping und das herunterladen einer XML-Datei die dann via FileFunktionen wieder eingelesen wurde. Kaum sind alle Dateioperationen (auch der Ini-Scheiss) auf Handles umgestellt worden habe ich das Problem nicht mehr beobachten können.

Zitat von KriZza

Der Debug hat mir auch hier kein Aufschluss gegeben.

Verstehe ich ehrlich gesagt nicht.
Um das mal krass zu formulieren willst du dass wir uns daran beteiligen im Nebel rumzustochern...

Was ist der SINN von Debugging?
Einen Fehler zu lokalisieren und diesen dann zu eliminieren. Der Sinn ist NICHT, irgendwelche Programmausgaben zu generieren, diese nicht zu beachten und darauf zu hoffen, dass sich der "Fehler" irgendwann selbst behebt oder irgendjemand anderes nach heftigem Reiben an der Kristallkugel eine Lösung in den Raum wirft!

Wenn dein Programm "einfriert", welche Funktion (Programmabschnitt, Zeile) wurde zuletzt ausgeführt? Wie ist der Inhalt der in dieser Funktion benutzten Variablen?

Zitat von KriZza

Meint ihr das GDI Funktionen so ein verhalten verursachen können?

Es wäre nicht das erste mal, dass in einer esoterischen Funktion Bugs enthalten sein können, bei den "Standard"-GDI-Funktionen schließe ich das aber aus. IdR. werden dort nur die API-Aufrufe gewrappert.

Zitat von KriZza

2 Dinge habe ich geändert und der Fehler ist bislang nicht mehr aufgetaucht

So gehts auch, was war der Anlaß dafür?